summaryrefslogtreecommitdiff
path: root/t/t5313-pack-bounds-checks.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-03-27t/helper: merge test-genrandom into test-toolLibravatar Nguyễn Thái Ngọc Duy1-2/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-07t5313: make extended-table test more deterministicLibravatar Jeff King1-1/+7
Commit a1283866b (t5313: test bounds-checks of corrupted/malicious pack/idx files, 2016-02-25) added a test that requires our corrupted pack index to have two objects. The entry for the first one remains untouched, but we corrupt the entry for second one. Since the index stores the entries in sha1-sorted order, this means that the test must make sure that the sha1 of the object we expect to be corrupted ("$object") sorts after the other placeholder object. That commit used the HEAD commit as the placeholder, but the script never calls test_tick. That means that the commit object (and thus its sha1) depends on the timestamp when the test script is run. This usually works in practice, because the sha1 of $object starts with "fff". The commit object will sort after that only 1 in 4096 times, but when it does the test will fail. One obvious solution is to add the test_tick call to get a deterministic commit sha1. But since we're relying on the sort order for the test to function, let's make that very explicit by just generating a second blob with a known sha1. Reported-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25use_pack: handle signed off_t overflowLibravatar Jeff King1-1/+1
A v2 pack index file can specify an offset within a packfile of up to 2^64-1 bytes. On a system with a signed 64-bit off_t, we can represent only up to 2^63-1. This means that a corrupted .idx file can end up with a negative offset in the pack code. Our bounds-checking use_pack function looks for too-large offsets, but not for ones that have wrapped around to negative. Let's do so, which fixes an out-of-bounds access demonstrated in t5313. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25nth_packed_object_offset: bounds-check extended offsetLibravatar Jeff King1-1/+1
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>
2016-02-25t5313: test bounds-checks of corrupted/malicious pack/idx filesLibravatar Jeff King1-0/+179
Our on-disk .pack and .idx files may reference other data by offset. We should make sure that we are not fooled by corrupt data into accessing memory outside of our mmap'd boundaries. This patch adds a series of tests for offsets found in .pack and .idx files. For the most part we get this right, but there are two tests of .idx files marked as failures: we do not bounds-check offsets in the v2 index's extended offset table, nor do we handle .idx offsets that overflow a signed off_t. With these tests, we should have good coverage of all offsets found in these files. Note that this doesn't cover .bitmap files, which may have similar bugs. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>