From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Jacek Wielemborek <d33tah@gmail.com>, git@vger.kernel.org
Subject: Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3
Date: Thu, 07 Jan 2016 14:54:50 -0800 [thread overview]
Message-ID: <xmqqtwmp2e6d.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <xmqqr3ht41w8.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Thu, 07 Jan 2016 11:37:11 -0800")
When we map in the .idx file, we do only minimum sanity checks to
make sure that the .idx file itself has sorted fan-out. We do not
check if the object names are sorted, so a bogus .idx could tell us
that an object does not exist when it exists in the matching .pack,
but that is harmless. Also an unsorted object names will not make
our binary search run in circles while looking things up.
We do not check if the offset of individual objects are within the
corresponding .pack file, either, and nth_packed_object_offset()
does return the data read from .idx file that is not checked for
sanity. use_pack(), which is the helper used by the callers of
nth_packed_object_offset() that finds the offset in the packfile for
each object, avoids allowing a read access to mapped pack data
beyond the end of it, so it is OK to return bogus value that was
read from the .idx file from this function, but there is one
computation the function itself does using a possibly bogus value
read from the disk: to find out where in the secondary offset table
in the .idx file the offset in the packfile is stored.
---
This is not even compile tested; I just wanted to prevent people
from adding two unnecessary checks to this function following my
analysis in the previous message. I think returning bogus value
stored in a crafted .idx file from this function is OK, as the
offset will be first used by use_pack() and the sanity of the
offset, relative to the packfile size, is checked there, and an
offset that points to a random point in the packfile will be caught
by the pack reading code, either by unpack_compressed_entry() or by
patch_delta(), so that is also safe.
We do need to check the unprotected access here. Nobody else in
the current codepath protects us from this access attempting to
read an unmapped memory and segfault.
sha1_file.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/sha1_file.c b/sha1_file.c
index 73ccd49..8aca1f6 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2458,6 +2458,13 @@ off_t nth_packed_object_offset(const struct packed_git *p, uint32_t n)
off = ntohl(*((uint32_t *)(index + 4 * n)));
if (!(off & 0x80000000))
return off;
+
+ /* 8-byte offset table */
+ if ((p->index_size - (8 + 256 * 4 + 28 * p->num_objects + 40))
+ <
+ (off & 0x7fffffff) * 8)
+ die("offset beyond end of .idx file");
+
index += p->num_objects * 4 + (off & 0x7fffffff) * 8;
return (((uint64_t)ntohl(*((uint32_t *)(index + 0)))) << 32) |
ntohl(*((uint32_t *)(index + 4)));
next prev parent reply other threads:[~2016-01-07 22:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-05 13:44 Segmentation fault found while fuzzing .pack file under 2.7.0.rc3 Jacek Wielemborek
2016-01-05 15:24 ` Jeff King
2016-01-06 0:23 ` Jonathan Nieder
2016-01-06 7:23 ` Jeff King
2016-01-06 9:27 ` Jacek Wielemborek
2016-01-06 9:46 ` Duy Nguyen
2016-01-06 12:51 ` Jacek Wielemborek
2016-01-07 19:37 ` Junio C Hamano
2016-01-07 22:54 ` Junio C Hamano [this message]
2016-01-11 21:33 ` Jeff King
2016-02-24 11:05 ` Jeff King
2016-02-24 18:48 ` Junio C Hamano
2016-02-25 14:12 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqtwmp2e6d.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=d33tah@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.