All of lore.kernel.org
 help / color / mirror / Atom feed
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)));

  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.