pack-bitmap: bounds-check size of cache extension
authorJeff King <peff@peff.net>
Tue, 8 Dec 2020 22:03:24 +0000 (17:03 -0500)
committerJunio C Hamano <gitster@pobox.com>
Tue, 8 Dec 2020 22:48:15 +0000 (14:48 -0800)
commitec6c7b43679fcd7db00019a850636abc5c94e44e
tree05a6052938c3444d50d381880b7a9b9bc2eabf8f
parentca510902008e99168b4fca53660e10b7a68b37f1
pack-bitmap: bounds-check size of cache extension

A .bitmap file may have a "name hash cache" extension, which puts a
sequence of uint32_t values (one per object) at the end of the file.
When we see a flag indicating this extension, we blindly subtract the
appropriate number of bytes from our available length. However, if the
.bitmap file is too short, we'll underflow our length variable and wrap
around, thinking we have a very large length. This can lead to reading
out-of-bounds bytes while loading individual ewah bitmaps.

We can fix this by checking the number of available bytes when we parse
the header. The existing "truncated bitmap" test is now split into two
tests: one where we don't have this extension at all (and hence actually
do try to read a truncated ewah bitmap) and one where we realize
up-front that we can't even fit in the cache structure. We'll check
stderr in each case to make sure we hit the error we're expecting.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-bitmap.c
t/t5310-pack-bitmaps.sh