[PATCH 0/3] untracked cache parsing fixups

From: Jeff King <peff@peff.net>
Date: Apr 18, 2019, 21:14 UTC
Message-ID: <20190418211408.GA18011@sigill.intra.peff.net>
In-Reply-To: <xmqq7ec00z9t.fsf@gitster-ct.c.googlers.com>

[+cc Duy as the master of all things untracked-cache]

On Fri, Apr 12, 2019 at 10:48:30AM +0900, Junio C Hamano wrote:

Show 13 quoted lines

> > The right thing is probably something like:
> >
> >   eos = memchr(data, '\0', end - data);
> >   if (!eos)
> > 	return error("malformed untracked cache extension");
> >   len = eos - data;
> >
> > I wouldn't be at all surprised if other bits of the index code have the
> > same issue, though. And at any rate, thinking about that should
> > definitely not hold up your fix.
> 
> True, true.  I wonder if folks intereseted in libFuzzer can chime in
> with something useful here, but that is totally independent.

Just so we don't forget about it, I wrote this fix up as a patch. And in fact it led to a few other cleanups. I think the first one is definitely worth doing now, even if there are other similar cases lurking in the rest of the index code.

The other two are optional, though I think they are worth it (and not too hard to verify that they are doing the right thing).

These are on top of js/untracked-cache-allocfix (though they could easily be ported to a separate topic if we want).

  [1/3]: untracked-cache: be defensive about missing NULs in index
  [2/3]: untracked-cache: simplify parsing by dropping "next"
  [3/3]: untracked-cache: simplify parsing by dropping "len"

 dir.c | 41 ++++++++++++++++++-----------------------
 1 file changed, 18 insertions(+), 23 deletions(-)

-Peff