git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	"Shawn O. Pearce" <spearce@spearce.org>
Subject: [PATCH v3 04/19] fetch-pack: fix out-of-bounds buffer offset in get_ack
Date: Wed, 20 Feb 2013 15:00:28 -0500	[thread overview]
Message-ID: <20130220200028.GD25647@sigill.intra.peff.net> (raw)
In-Reply-To: <20130220195147.GA25332@sigill.intra.peff.net>

When we read acks from the remote, we expect either:

  ACK <sha1>

or

  ACK <sha1> <multi-ack-flag>

We parse the "ACK <sha1>" bit from the line, and then start
looking for the flag strings at "line+45"; if we don't have
them, we assume it's of the first type.  But if we do have
the first type, then line+45 is not necessarily inside our
string at all!

It turns out that this works most of the time due to the way
we parse the packets. They should come in with a newline,
and packet_read puts an extra NUL into the buffer, so we end
up with:

  ACK <sha1>\n\0

with the newline at offset 44 and the NUL at offset 45. We
then strip the newline, putting a NUL at offset 44. So
when we look at "line+45", we are looking past the end of
our string; but it's OK, because we hit the terminator from
the original string.

This breaks down, however, if the other side does not
terminate their packets with a newline. In that case, our
packet is one character shorter, and we start looking
through uninitialized memory for the flag. No known
implementation sends such a packet, so it has never come up
in practice.

This patch tightens the check by looking for a short,
flagless ACK before trying to parse the flag.

Signed-off-by: Jeff King <peff@peff.net>
---
This is the absolute minimal fix, which just checks for the no-flag case
early; we still treat arbitrary crud in the flag field as just an ACK.
From my understanding of the protocol, a saner parsing scheme would be:

  const char *flag = line + 44; /* we already parsed "ACK <sha1>" */
  if (!*flag)
          return ACK;
  if (!strcmp(flag, " continue"))
          return ACK_continue;
  if (!strcmp(flag, " common"))
          return ACK_continue;
  if (!strcmp(flag, " ready"))
          return ACK_ready;
  die("fetch-pack expected multi-ack flag, got: %s", line);

But that is much tighter, and I wasn't sure if the looseness was there
to facilitate future expansion or something (though I'd think we would
need a new capability for that).

 fetch-pack.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fetch-pack.c b/fetch-pack.c
index 6d8926a..27a3e80 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -226,6 +226,8 @@ static enum ack_type get_ack(int fd, unsigned char *result_sha1)
 		return NAK;
 	if (!prefixcmp(line, "ACK ")) {
 		if (!get_sha1_hex(line+4, result_sha1)) {
+			if (len < 45)
+				return ACK;
 			if (strstr(line+45, "continue"))
 				return ACK_continue;
 			if (strstr(line+45, "common"))
-- 
1.8.2.rc0.9.g352092c

  parent reply	other threads:[~2013-02-20 20:00 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-20 19:51 [PATCHv3 0/19] pkt-line cleanups and fixes Jeff King
2013-02-20 19:53 ` [PATCH v3 01/19] upload-pack: use get_sha1_hex to parse "shallow" lines Jeff King
2013-02-20 19:54 ` [PATCH v3 02/19] upload-pack: do not add duplicate objects to shallow list Jeff King
2013-02-20 19:55 ` [PATCH v3 03/19] upload-pack: remove packet debugging harness Jeff King
2013-02-20 20:00 ` Jeff King [this message]
2013-02-20 20:00 ` [PATCH v3 05/19] send-pack: prefer prefixcmp over memcmp in receive_status Jeff King
2013-02-20 20:00 ` [PATCH v3 06/19] upload-archive: do not copy repo name Jeff King
2013-02-20 20:01 ` [PATCH v3 07/19] upload-archive: use argv_array to store client arguments Jeff King
2013-02-20 20:01 ` [PATCH v3 08/19] write_or_die: raise SIGPIPE when we get EPIPE Jeff King
2013-02-20 21:51   ` Jonathan Nieder
2013-02-20 21:58     ` Jeff King
2013-02-20 22:01       ` Jonathan Nieder
2013-02-20 22:03         ` Jeff King
2013-02-20 22:06           ` Jonathan Nieder
2013-02-20 22:12             ` Jeff King
2013-02-20 22:19               ` Junio C Hamano
2014-03-28  8:35   ` [BUG] MSVC: error box when interrupting `gitlog` by quitting less Marat Radchenko
2014-03-28  9:14     ` Marat Radchenko
2014-03-28  9:44       ` Jeff King
2014-03-28 10:07         ` Marat Radchenko
2014-03-28 10:19           ` Jeff King
2014-03-28 10:28           ` Johannes Sixt
2014-03-28 11:19             ` [PATCH] MSVC: link in invalidcontinue.obj for better POSIX compatibility Marat Radchenko
2014-03-28 18:27               ` Junio C Hamano
2014-03-28 18:46                 ` Marat Radchenko
2014-03-28 19:06                 ` Junio C Hamano
2014-03-28 20:08                   ` [PATCH v2] " Marat Radchenko
2014-03-28 20:35                     ` Junio C Hamano
2013-02-20 20:01 ` [PATCH v3 09/19] pkt-line: move a misplaced comment Jeff King
2013-02-20 20:01 ` [PATCH v3 10/19] pkt-line: drop safe_write function Jeff King
2013-02-20 20:02 ` [PATCH v3 11/19] pkt-line: provide a generic reading function with options Jeff King
2013-02-20 20:02 ` [PATCH v3 12/19] pkt-line: teach packet_read_line to chomp newlines Jeff King
2013-02-20 20:02 ` [PATCH v3 13/19] pkt-line: move LARGE_PACKET_MAX definition from sideband Jeff King
2013-02-20 20:02 ` [PATCH v3 14/19] pkt-line: provide a LARGE_PACKET_MAX static buffer Jeff King
2013-02-20 20:04 ` [PATCH v3 15/19] pkt-line: share buffer/descriptor reading implementation Jeff King
2013-02-22 11:22   ` Eric Sunshine
2013-02-20 20:06 ` [PATCH v3 16/19] teach get_remote_heads to read from a memory buffer Jeff King
2013-02-20 20:07 ` [PATCH v3 17/19] remote-curl: pass buffer straight to get_remote_heads Jeff King
2013-02-20 20:07 ` [PATCH v3 18/19] remote-curl: move ref-parsing code up in file Jeff King
2013-02-20 20:07 ` [PATCH v3 19/19] remote-curl: always parse incoming refs 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=20130220200028.GD25647@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=spearce@spearce.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).