]> git.ipfire.org Git - thirdparty/git.git/commit - builtin/index-pack.c
nth_packed_object_offset: bounds-check extended offset
authorJeff King <peff@peff.net>
Thu, 25 Feb 2016 14:22:52 +0000 (09:22 -0500)
committerJunio C Hamano <gitster@pobox.com>
Thu, 25 Feb 2016 19:32:43 +0000 (11:32 -0800)
commit47fe3f6ef0f5a336db90d816c5fb4330ffa23668
tree86425f817d2e2116956355c387cafd78b50e9877
parenta1283866bab1cd12da57b3e427664180f5dee333
nth_packed_object_offset: bounds-check extended offset

If a pack .idx file has a corrupted offset for an object, we
may try to access an offset in the .idx or .pack file that
is larger than the file's size.  For the .pack case, we have
use_pack() to protect us, which realizes the access is out
of bounds. But if the corrupted value asks us to look in the
.idx file's secondary 64-bit offset table, we blindly add it
to the mmap'd index data and access arbitrary memory.

We can fix this with a simple bounds-check compared to the
size we found when we opened the .idx file.

Note that there's similar code in index-pack that is
triggered only during "index-pack --verify". To support
both, we pull the bounds-check into a separate function,
which dies when it sees a corrupted file.

It would be nice if we could return an error, so that the
pack code could try to find a good copy of the object
elsewhere. Currently nth_packed_object_offset doesn't have
any way to return an error, but it could probably use "0" as
a sentinel value (since no object can start there). This is
the minimal fix, and we can improve the resilience later on
top.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/index-pack.c
cache.h
sha1_file.c
t/t5313-pack-bounds-checks.sh