Re: [PATCH] tree-walk: disallow overflowing modes

From: Jeff King <peff@peff.net>
Date: Jan 22, 2023, 22:02 UTC
Message-ID: <Y82yXskkgH00vaGy@coredump.intra.peff.net>
In-Reply-To: <044bdc8f-fdc9-dfd2-6cbb-941513467524@web.de>

On Sun, Jan 22, 2023 at 11:03:38AM +0100, René Scharfe wrote:

Show 14 quoted lines

> Am 22.01.23 um 08:50 schrieb Jeff King:
> > On Sat, Jan 21, 2023 at 10:36:09AM +0100, René Scharfe wrote:
> >
> >> When parsing tree entries, reject mode values that don't fit into an
> >> unsigned int.
> >
> > Seems reasonable. I don't think you can cause any interesting mischief
> > here, but it's cheap to check, and finding data problems earlier rather
> > than later is always good.
> >
> > Should it be s/unsigned int/uint16_t/, though?
> 
> "mode" is declared as unsigned int, and I was more concerned with
> overflowing that.

Doh, I just did "vim -t get_mode" and ended up in the near-identical version in fast-import.c, which uses uint16_t. Maybe it would want the same treatment. ;)

> We could be more strict and reject everything that oversteps
> S_IFMT|ALLPERMS, but the latter is not defined everywhere.  But
> permission bits are well-known, so the magic number 07777 should be
> recognizable enough.  Like this?

It feels like this level of check should be happening in the fsck caller. In particular, it's nice for this parsing layer to err on the forgiving side, because the way you get out of these situations often involves something like "git ls-tree | git mktree".

So in that sense, even pushing the overflow detection into the fsck would be nice, but of course it's hard to do, since we have no way to represent the overflowed value. I guess we could have a "be more careful" flag that the fsck code would pass, but I'm not sure it's worth the added complexity.

-Peff