git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: demerphq <demerphq@gmail.com>, Git <git@vger.kernel.org>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: [PATCH 8/7] read_pack_header: handle signed/unsigned comparison in read result
Date: Wed, 13 Sep 2017 14:47:22 -0400	[thread overview]
Message-ID: <20170913184722.imcexldnufskugqz@sigill.intra.peff.net> (raw)
In-Reply-To: <20170913170807.cyx7rrpoyhaauvol@sigill.intra.peff.net>

On Wed, Sep 13, 2017 at 01:08:07PM -0400, Jeff King wrote:

> Here's the fix, along with some related cleanups. The actual bugfix is
> in the first patch, which I think should go to "maint". The rest are not
> as important, so could go to master (but would also be fine for maint,
> as there should be no user-visible changes).
> 
>   [1/7]: config: avoid "write_in_full(fd, buf, len) < len" pattern
>   [2/7]: get-tar-commit-id: check write_in_full() return against 0
>   [3/7]: avoid "write_in_full(fd, buf, len) != len" pattern
>   [4/7]: convert less-trivial versions of "write_in_full() != len"
>   [5/7]: pkt-line: check write_in_full() errors against "< 0"
>   [6/7]: notes-merge: use ssize_t for write_in_full() return value
>   [7/7]: config: flip return value of store_write_*()

Jonathan pointed out that read_in_full() can suffer from the same issue,
and there is one buggy caller.

A mass cleanup is a bit harder, as described in

  https://public-inbox.org/git/20170913183700.amtrquhg66hjrbsp@sigill.intra.peff.net/

so I punted on it for now.

-- >8 --
Subject: [PATCH] read_pack_header: handle signed/unsigned comparison in read
 result

The result of read_in_full() may be -1 if we saw an error.
But in comparing it to a sizeof() result, that "-1" will be
promoted to size_t. In fact, the largest possible size_t
which is much bigger than our struct size. This means that
our "< sizeof(header)" error check won't trigger.

In practice, we'd go on to read uninitialized memory and
compare it to the PACK signature, which is likely to fail.
But we shouldn't get there.

We can fix this by making a direct "!=" comparison to the
requested size, rather than "<". This means that errors get
lumped in with short reads, but that's sufficient for our
purposes here. There's no PH_ERROR tp represent our case.
And anyway, this function reads from pipes and network
sockets. A network error may racily appear as EOF to us
anyway if there's data left in the socket buffers.

Signed-off-by: Jeff King <peff@peff.net>
---
 sha1_file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sha1_file.c b/sha1_file.c
index 5f71bbac3e..c1c6e9021d 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1850,7 +1850,7 @@ int index_path(struct object_id *oid, const char *path, struct stat *st, unsigne
 
 int read_pack_header(int fd, struct pack_header *header)
 {
-	if (read_in_full(fd, header, sizeof(*header)) < sizeof(*header))
+	if (read_in_full(fd, header, sizeof(*header)) != sizeof(*header))
 		/* "eof before pack header was fully read" */
 		return PH_ERROR_EOF;
 
-- 
2.14.1.874.ge7b2e05270


  parent reply	other threads:[~2017-09-13 18:47 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-13 11:59 Bug: git branch --unset-upstream command can nuke config when disk is full demerphq
2017-09-13 12:34 ` Jeff King
2017-09-13 13:38   ` demerphq
2017-09-13 14:17     ` Jeff King
2017-09-13 14:49       ` demerphq
2017-09-13 14:51         ` Jeff King
2017-09-13 15:18           ` demerphq
2017-09-13 15:22             ` Jeff King
2017-09-13 15:49               ` demerphq
2017-09-13 17:08 ` [PATCH 0/7] config.c may fail to notice some write() failures Jeff King
2017-09-13 17:11   ` [PATCH 1/7] config: avoid "write_in_full(fd, buf, len) < len" pattern Jeff King
2017-09-13 17:47     ` Jonathan Nieder
2017-09-13 17:53       ` Jeff King
2017-09-13 17:59         ` Jonathan Nieder
2017-09-13 18:11           ` Jeff King
2017-09-13 18:15     ` [PATCH v2] " Jeff King
2017-09-13 18:24       ` Jonathan Nieder
2017-09-13 18:58         ` Jeff King
2017-09-13 19:18           ` Jonathan Nieder
2017-09-13 19:49           ` Jonathan Nieder
2017-09-13 22:43           ` Ramsay Jones
2017-09-13 23:31             ` Ramsay Jones
2017-09-15  0:37               ` Jeff King
2017-09-15 15:15                 ` Ramsay Jones
2017-09-13 21:33         ` Junio C Hamano
2017-09-13 17:11   ` [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0 Jeff King
2017-09-13 17:53     ` Jonathan Nieder
2017-09-13 18:02       ` Jeff King
2017-09-13 18:37         ` Jeff King
2017-09-13 21:09     ` Jonathan Nieder
2017-09-15  0:40       ` Jeff King
2017-09-13 17:16   ` [PATCH 3/7] avoid "write_in_full(fd, buf, len) != len" pattern Jeff King
2017-09-13 21:14     ` Jonathan Nieder
2017-09-15  0:42       ` Jeff King
2017-09-13 17:16   ` [PATCH 4/7] convert less-trivial versions of "write_in_full() != len" Jeff King
2017-09-13 21:16     ` Jonathan Nieder
2017-09-13 17:17   ` [PATCH 5/7] pkt-line: check write_in_full() errors against "< 0" Jeff King
2017-09-13 21:17     ` Jonathan Nieder
2017-09-13 17:17   ` [PATCH 6/7] notes-merge: use ssize_t for write_in_full() return value Jeff King
2017-09-13 21:20     ` Jonathan Nieder
2017-09-15  0:43       ` Jeff King
2017-09-13 17:17   ` [PATCH 7/7] config: flip return value of store_write_*() Jeff King
2017-09-13 21:25     ` Jonathan Nieder
2017-09-15  0:46       ` Jeff King
2017-09-13 18:47   ` Jeff King [this message]
2017-09-13 19:11     ` [PATCH 8/7] read_pack_header: handle signed/unsigned comparison in read result Jonathan Nieder

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170913184722.imcexldnufskugqz@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=demerphq@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).