]> git.ipfire.org Git - thirdparty/git.git/commit - dir.c
untracked-cache: be defensive about missing NULs in index
authorJeff King <peff@peff.net>
Thu, 18 Apr 2019 21:17:02 +0000 (17:17 -0400)
committerJunio C Hamano <gitster@pobox.com>
Fri, 19 Apr 2019 05:27:07 +0000 (14:27 +0900)
commitc6909f9959d394db8b76f08a6e59e5a82dade07a
treed0162569131416fdc380f1d5c3d806db7f74ffea
parent3a7b45a62360ff0e14f7150ee2d9930c0c258dbd
untracked-cache: be defensive about missing NULs in index

The on-disk format for the untracked-cache extension contains
NUL-terminated filenames. We parse these from the mmap'd file using
string functions like strlen(). This works fine in the normal case, but
if we see a malformed or corrupted index, we might read off the end of
our mmap.

Instead, let's use memchr() to find the trailing NUL within the bytes we
know are available, and return an error if it's missing.

Note that we can further simplify by folding another range check into
our conditional. After we find the end of the string, we set "next" to
the byte after the string and treat it as an error if there are no such
bytes left. That saves us from having to do a range check at the
beginning of each subsequent string (and works because there is always
data after each string). We can do both range checks together by
checking "!eos" (we didn't find a NUL) and "eos == end" (it was on the
last available byte, meaning there's nothing after). This replaces the
existing "next > end" checks.

Note also that the decode_varint() calls have a similar problem (we
don't even pass them "end"; they just keep parsing). These are probably
OK in practice since varints have a finite length (we stop parsing when
we'd overflow a uintmax_t), so the worst case is that we'd overflow into
reading the trailing bytes of the index.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
dir.c