Integer-overflow in read-cache.c can cause buffer-overflow (bug requires a crafted/corrupted index)

Hi,

I had a procastination episode today and wrote https://glandium.org/blog/?p=3659 . It started with me looking what git was doing with the size of the index when writing the index header, leading me to find a rather improbable integer overflow in https://github.com/git/git/blob/5c589a73de4394ad125a4effac227b3aec856fa1/read-cache.c#L1040 requiring hundreds of gigabytes of memory before happening.

But right after I finished the post and clicked "publish", I actually looked at the reading side and found another separate integer overflow that can lead to buffer overflow.

The possible integer overflow is here: https://github.com/git/git/blob/5c589a73de4394ad125a4effac227b3aec856fa1/read-cache.c#L1589

where alloc_nr is: #define alloc_nr(x) (((x)+16)*3/2)

So a crafter header with a number of entries above 1.something billion would overflow (cache_nr is an unsigned int), and istate->cache would be allocated with less than it should.

Then there can be a buffer overflow when reading the entries.

But this all require a crafted or corrupted index. If an attacker has been able to alter your index, you've already lost.

So I'd say the risk is rather low on the security scale.

Cheers,

Mike