diff options
author | Jeff King <peff@peff.net> | 2019-04-18 17:17:02 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2019-04-19 14:27:07 +0900 |
commit | c6909f9959d394db8b76f08a6e59e5a82dade07a (patch) | |
tree | d0162569131416fdc380f1d5c3d806db7f74ffea /t/t6044-merge-unrelated-index-changes.sh | |
parent | untracked cache: fix off-by-one (diff) | |
download | tgif-c6909f9959d394db8b76f08a6e59e5a82dade07a.tar.xz |
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>
Diffstat (limited to 't/t6044-merge-unrelated-index-changes.sh')
0 files changed, 0 insertions, 0 deletions