@matheusbsbs / matheus-bagliano / commits / 168a937bbc

object-file: fix SEGV on free() regression in v2.34.0-rc2

Fix a regression introduced in my 96e41f58fe1 (fsck: report invalid object type-path combinations, 2021-10-01). When fsck-ing blobs larger than core.bigFileThreshold, we'd free() a pointer to uninitialized memory. This issue would have been caught by SANITIZE=address, but since it involves core.bigFileThreshold, none of the existing tests in our test suite covered it. Running them with the "big_file_threshold" in "environment.c" changed to say "6" would have shown this failure, but let's add a dedicated test for this scenario based on Han Xin's report[1]. The bug was introduced between v9 and v10[2] of the fsck series merged in 061a21d36d8 (Merge branch 'ab/fsck-unexpected-type', 2021-10-25). 1. https://lore.kernel.org/git/20211111030302.75694-1-hanxin.hx@alibaba-inc.com/ 2. https://lore.kernel.org/git/cover-v10-00.17-00000000000-20211001T091051Z-avarab@gmail.com/ Reported-by: Han Xin <chiyutianyi@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Ævar Arnfjörð Bjarmason committed Nov 11, 2021 at 06:18 UTC 168a937bbcf74370267fe04f5368035948745baa
2 files changed +10
object-file.c
+2
@@ -2533,6 +2533,8 @@ int read_loose_object(const char *path,
2533 char hdr[MAX_HEADER_LEN];
2534 unsigned long *size = oi->sizep;
2535
2536 + *contents = NULL;
2537 +
2538 map = map_loose_object_1(the_repository, path, NULL, &mapsize);
2539 if (!map) {
2540 error_errno(_("unable to mmap %s"), path);
t/t1050-large.sh
+8
@@ -17,6 +17,14 @@ test_expect_success setup '
17 export GIT_ALLOC_LIMIT
18 '
19
20 +test_expect_success 'enter "large" codepath, with small core.bigFileThreshold' '
21 + test_when_finished "rm -rf repo" &&
22 +
23 + git init --bare repo &&
24 + echo large | git -C repo hash-object -w --stdin &&
25 + git -C repo -c core.bigfilethreshold=4 fsck
26 +'
27 +
28 # add a large file with different settings
29 while read expect config
30 do