Re: [RFC/PATCH 0/6] hash-object: use fsck to check objects

From: René Scharfe <l.s.r@web.de>
Date: Jan 21, 2023, 09:36 UTC
Message-ID: <97faa323-a5b9-e459-70d7-3f6318446898@web.de>
In-Reply-To: <Y8ifa7hyqxSbL92U@coredump.intra.peff.net>

Am 19.01.23 um 02:39 schrieb Jeff King:

>
> Though I do find the use of strlen() in decode_tree_entry()
> a little suspicious (and that would be true of the current code, as
> well, since it powers hash-object's existing parsing check).

strlen() won't overrun the buffer because the first check in decode_tree_entry() makes sure there is a NUL in the buffer ahead. If get_mode() crosses it then we exit early.

Storing the result in an unsigned int can overflow on platforms where size_t is bigger. That would result in pathlen values being too short for really long paths, but no out-of-bounds access. They are then stored as signed int in struct name_entry and used as such in many places -- that seems like a bad idea, but I didn't actually check them thoroughly.

get_mode() can overflow "mode" if there are too many octal digits. Do we need to accept more than two handfuls in the first place? I'll send a patch for at least rejecting overflow.

Hmm, what would be the performance impact of trees with mode fields zero-padded to silly lengths?

René