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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html