[PATCH 0/2] Fix NULL checks for some packet_read_line call sites

[PATCH 0/2] Fix NULL checks for some packet_read_line call sites

[Jon Simons]

Included here are a couple of fixes and cleanups for
handling NULL return values from 'packet_read_line'.

Jeff King (1):
  correct error messages for NULL packet_read_line()

Jon Simons (1):
  always check for NULL return from packet_read_line()

 builtin/archive.c | 2 +-
 fetch-pack.c      | 4 ++--
 remote-curl.c     | 2 ++
 send-pack.c       | 2 ++
 4 files changed, 7 insertions(+), 3 deletions(-)

-- 
2.1.4

[PATCH 1/2] correct error messages for NULL packet_read_line()

[Jon Simons]

From: Jeff King <peff@peff.net>

The packet_read_line() function dies if it gets an
unexpected EOF. It only returns NULL if we get a flush
packet (or technically, a zero-length "0004" packet, but
nobody is supposed to send those, and they are
indistinguishable from a flush in this interface).

Let's correct error messages which claim an unexpected EOF;
it's really an unexpected flush packet.

While we're here, let's also check "!line" instead of
"!len" in the second case. The two events should always
coincide, but checking "!line" makes it more obvious that we
are not about to dereference NULL.

Signed-off-by: Jeff King <peff@peff.net>
---
 builtin/archive.c | 2 +-
 fetch-pack.c      | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/builtin/archive.c b/builtin/archive.c
index f863465..73971d0 100644
--- a/builtin/archive.c
+++ b/builtin/archive.c
@@ -55,7 +55,7 @@ static int run_remote_archiver(int argc, const char **argv,
 
 	buf = packet_read_line(fd[0], NULL);
 	if (!buf)
-		die(_("git archive: expected ACK/NAK, got EOF"));
+		die(_("git archive: expected ACK/NAK, got a flush packet"));
 	if (strcmp(buf, "ACK")) {
 		if (starts_with(buf, "NACK "))
 			die(_("git archive: NACK %s"), buf + 5);
diff --git a/fetch-pack.c b/fetch-pack.c
index a376b4e..1b7cd6b 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -262,8 +262,8 @@ static enum ack_type get_ack(int fd, struct object_id *result_oid)
 	char *line = packet_read_line(fd, &len);
 	const char *arg;
 
-	if (!len)
-		die(_("git fetch-pack: expected ACK/NAK, got EOF"));
+	if (!line)
+		die(_("git fetch-pack: expected ACK/NAK, got a flush packet"));
 	if (!strcmp(line, "NAK"))
 		return NAK;
 	if (skip_prefix(line, "ACK ", &arg)) {
-- 
2.1.4

[PATCH 2/2] always check for NULL return from packet_read_line()

[Jon Simons]

The packet_read_line() function will die if it sees any
protocol or socket errors. But it will return NULL for a
flush packet; some callers which are not expecting this may
dereference NULL if they get an unexpected flush. This would
involve the other side breaking protocol, but we should
flag the error rather than segfault.

Signed-off-by: Jon Simons <jon@jonsimons.org>
---
 remote-curl.c | 2 ++
 send-pack.c   | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/remote-curl.c b/remote-curl.c
index 0053b09..9903077 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -339,6 +339,8 @@ static struct discovery *discover_refs(const char *service, int for_push)
 		 * pkt-line matches our request.
 		 */
 		line = packet_read_line_buf(&last->buf, &last->len, NULL);
+		if (!line)
+			die("invalid server response; expected service, got flush packet");
 
 		strbuf_reset(&exp);
 		strbuf_addf(&exp, "# service=%s", service);
diff --git a/send-pack.c b/send-pack.c
index 11d6f3d..d37b265 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -147,6 +147,8 @@ static int pack_objects(int fd, struct ref *refs, struct oid_array *extra, struc
 static int receive_unpack_status(int in)
 {
 	const char *line = packet_read_line(in, NULL);
+	if (!line)
+		return error(_("unexpected flush packet while reading remote unpack status"));
 	if (!skip_prefix(line, "unpack ", &line))
 		return error(_("unable to parse remote unpack status: %s"), line);
 	if (strcmp(line, "ok"))
-- 
2.1.4

Re: [PATCH 2/2] always check for NULL return from packet_read_line()

[Jeff King]

On Thu, Feb 08, 2018 at 01:47:50PM -0500, Jon Simons wrote:

> The packet_read_line() function will die if it sees any
> protocol or socket errors. But it will return NULL for a
> flush packet; some callers which are not expecting this may
> dereference NULL if they get an unexpected flush. This would
> involve the other side breaking protocol, but we should
> flag the error rather than segfault.

As one might guess from the dual authorship on this series, Jon and I
discussed these off list. So this one is

  Reviewed-by: Jeff King <peff@peff.net>

And the other one, too, but I'm not sure that carries any weight. :)

-Peff