summaryrefslogtreecommitdiff
path: root/list-objects.c
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2020-12-08 17:03:19 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-12-08 14:48:15 -0800
commitca510902008e99168b4fca53660e10b7a68b37f1 (patch)
tree6dd57395c32d2e39c619bb07cb4e6ba42fd375a9 /list-objects.c
parentewah/ewah_bitmap.c: avoid open-coding ALLOC_GROW() (diff)
downloadtgif-ca510902008e99168b4fca53660e10b7a68b37f1.tar.xz
pack-bitmap: fix header size check
When we parse a .bitmap header, we first check that we have enough bytes to make a valid header. We do that based on sizeof(struct bitmap_disk_header). However, as of 0f4d6cada8 (pack-bitmap: make bitmap header handling hash agnostic, 2019-02-19), that struct oversizes its checksum member to GIT_MAX_RAWSZ. That means we need to adjust for the difference between that constant and the size of the actual hash we're using. That commit adjusted the code which moves our pointer forward, but forgot to update the size check. This meant we were overly strict about the header size (requiring room for a 32-byte worst-case hash, when sha1 is only 20 bytes). But in practice it didn't matter because bitmap files tend to have at least 12 bytes of actual data anyway, so it was unlikely for a valid file to be caught by this. Let's fix it by pulling the header size into a separate variable and using it in both spots. That fixes the bug and simplifies the code to make it harder to have a mismatch like this in the future. It will also come in handy in the next patch for more bounds checking. 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>
Diffstat (limited to 'list-objects.c')
0 files changed, 0 insertions, 0 deletions