diff options
author | Jeff King <peff@peff.net> | 2020-12-08 17:03:19 -0500 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2020-12-08 14:48:15 -0800 |
commit | ca510902008e99168b4fca53660e10b7a68b37f1 (patch) | |
tree | 6dd57395c32d2e39c619bb07cb4e6ba42fd375a9 /object.c | |
parent | ewah/ewah_bitmap.c: avoid open-coding ALLOC_GROW() (diff) | |
download | tgif-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 'object.c')
0 files changed, 0 insertions, 0 deletions