summaryrefslogtreecommitdiff
path: root/git.spec.in
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2016-02-25 09:22:52 -0500
committerJunio C Hamano <gitster@pobox.com>2016-02-25 11:32:43 -0800
commit47fe3f6ef0f5a336db90d816c5fb4330ffa23668 (patch)
tree86425f817d2e2116956355c387cafd78b50e9877 /git.spec.in
parenta1283866bab1cd12da57b3e427664180f5dee333 (diff)
downloadgit-47fe3f6ef0f5a336db90d816c5fb4330ffa23668.tar.gz
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>
Diffstat (limited to 'git.spec.in')
0 files changed, 0 insertions, 0 deletions