{"thread":{"id":"42801","subject":"Integer-overflow in read-cache.c can cause buffer-overflow (bug requires a crafted/corrupted index)","startedAt":"2016-07-08T11:43:12Z","lastAt":"2016-07-08T11:43:12Z","messageCount":1,"participants":["Mike Hommey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"291029","messageId":"20160708114302.GA20350@glandium.org","threadId":"42801","inReplyTo":null,"subject":"Integer-overflow in read-cache.c can cause buffer-overflow (bug requires a crafted/corrupted index)","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-07-08T11:43:02Z","receivedAt":"2016-07-08T11:43:12Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nI had a procastination episode today and wrote\nhttps://glandium.org/blog/?p=3659 . It started with me looking what git\nwas doing with the size of the index when writing the index header,\nleading me to find a rather improbable integer overflow in\nhttps://github.com/git/git/blob/5c589a73de4394ad125a4effac227b3aec856fa1/read-cache.c#L1040\nrequiring hundreds of gigabytes of memory before happening.\n\nBut right after I finished the post and clicked \"publish\", I actually\nlooked at the reading side and found another separate integer overflow\nthat can lead to buffer overflow.\n\nThe possible integer overflow is here:\nhttps://github.com/git/git/blob/5c589a73de4394ad125a4effac227b3aec856fa1/read-cache.c#L1589\n\nwhere alloc_nr is:\n#define alloc_nr(x) (((x)+16)*3/2)\n\nSo a crafter header with a number of entries above 1.something billion\nwould overflow (cache_nr is an unsigned int), and istate->cache would\nbe allocated with less than it should.\n\nThen there can be a buffer overflow when reading the entries.\n\nBut this all require a crafted or corrupted index. If an attacker has\nbeen able to alter your index, you've already lost.\n\nSo I'd say the risk is rather low on the security scale.\n\nCheers,\n\nMike\n"}]}