[0/3] untracked cache parsing fixups

Message

Jeff King April 18, 2019, 9:14 p.m. UTC

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

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

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