list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
Cc: Taylor Blau <>
Subject: [PATCH 2/3] revision: avoid out-of-bounds read/write on empty pathspec
Date: Tue, 4 Aug 2020 03:46:52 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Running t4216 with ASan results in it complaining of an out-of-bounds
read in prepare_to_use_bloom_filter(). The issue is this code to strip a
trailing slash:

  last_index = pi->len - 1;
  if (pi->match[last_index] == '/') {

because we have no guarantee that pi->len isn't zero. This can happen if
the pathspec is ".", as we translate that to an empty string. And if
that read of random memory does trigger the conditional, we'd then do an
out-of-bounds write:

  path_alloc = xstrdup(pi->match);
  path_alloc[last_index] = '\0';

Let's make sure to check the length before subtracting. Note that for an
empty pathspec, we'd end up bailing from the function a few lines later,
which makes it tempting to just:

  if (!pi->len)

early here. But our code here is stripping a trailing slash, and we need
to check for emptiness after stripping that slash, too. So we'd have two
blocks, which would require repeating some cleanup code.

Instead, just skip the trailing-slash for an empty string. Setting
last_index at all in the case is awkward since it will have a nonsense
value (and it uses an "int", which is a too-small type for a string
anyway). So while we're here, let's:

  - drop last_index entirely; it's only used in two spots right next to
    each other and writing out "pi->len - 1" in both is actually easier
    to follow

  - use xmemdupz() to duplicate the string. This is slightly more
    efficient, but more importantly makes the intent more clear by
    allocating the correct-sized substring in the first place. It also
    eliminates any question of whether path_alloc is as long as
    pi->match (which it would not be if pi->match has any embedded NULs,
    though in practice this is probably impossible).

Signed-off-by: Jeff King <>
Another variant is to actually stop assigning revs->bloom_filter_settings
so early, so that we don't have to clean it up. And then once we're sure
we're going to use it and have passed all of our early-return checks,
then assign it. But that conflicts with the get_bloom_filter_settings()
patch in:

so I didn't go that way.

 revision.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/revision.c b/revision.c
index 6de29cdf7a..5ed86e4524 100644
--- a/revision.c
+++ b/revision.c
@@ -669,7 +669,6 @@ static void prepare_to_use_bloom_filter(struct rev_info *revs)
 	struct pathspec_item *pi;
 	char *path_alloc = NULL;
 	const char *path, *p;
-	int last_index;
 	size_t len;
 	int path_component_nr = 1;
@@ -692,12 +691,10 @@ static void prepare_to_use_bloom_filter(struct rev_info *revs)
 	pi = &revs->pruning.pathspec.items[0];
-	last_index = pi->len - 1;
 	/* remove single trailing slash from path, if needed */
-	if (pi->match[last_index] == '/') {
-		path_alloc = xstrdup(pi->match);
-		path_alloc[last_index] = '\0';
+	if (pi->len > 0 && pi->match[pi->len - 1] == '/') {
+		path_alloc = xmemdupz(pi->match, pi->len - 1);
 		path = path_alloc;
 	} else
 		path = pi->match;

  parent reply	other threads:[~2020-08-04  7:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-04  7:41 [PATCH 0/3] some compiler/asan/ubsan fixes Jeff King
2020-08-04  7:43 ` [PATCH 1/3] config: work around gcc-10 -Wstringop-overflow warning Jeff King
2020-08-04 16:30   ` Junio C Hamano
2020-08-05 15:15     ` Taylor Blau
2020-08-04  7:46 ` Jeff King [this message]
2020-08-04 13:08   ` [PATCH 2/3] revision: avoid out-of-bounds read/write on empty pathspec Derrick Stolee
2020-08-05 15:17   ` Taylor Blau
2020-08-04  7:50 ` [PATCH 3/3] revision: avoid leak when preparing bloom filter for "/" Jeff King
2020-08-04 13:09   ` Derrick Stolee
2020-08-05 15:19     ` Taylor Blau

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:

  List information:

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

  git send-email \ \ \ \ \

* 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

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).