Re: [PATCH 6/6] config: reject parsing of files over INT_MAX
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Apr 13, 2020, 00:47 UTC
- Message-ID
- <20200413004724.GB55122@syl.local>
- In-Reply-To
- <20200410221549.GA2078378@coredump.intra.peff.net>
On Fri, Apr 10, 2020 at 06:15:49PM -0400, Jeff King wrote:
Show 31 quoted lines
> On Fri, Apr 10, 2020 at 03:04:31PM -0700, Junio C Hamano wrote:
>
> > Jeff King <peff@peff.net> writes:
> >
> > > So given the fact that these are insane cases which we have no need to
> > > support, the weird behavior from feeding the results to printf even if
> > > the code is careful, and the possibility of uncareful code introducing
> > > its own integer truncation issues, let's just declare INT_MAX as a limit
> > > for parsing config files.
> >
> > Makes sense.
> >
> > > + if (c != EOF && ++cf->total_len > INT_MAX) {
> >
> > Would this work correctly if size_t is uint? Sure, as int-max would
> > fit within it. And of course if size_t is wider than uint, there is
> > no problem in this comparison.
>
> Good question, but yeah, I think it's right.
>
> Another method would be to do:
>
> if (cf->total_len >= INT_MAX)
>
> _before_ reading any character. We'd have to remember to increment
> total_len then (I suppose we could do it preemptively; as long as people
> don't try to read EOF from us over and over again it would never move
> again).
>
> I also considered making the limit much lower than INT_MAX because
> really, who needs even a 1GB config file? :);). Making it lower than INT_MAX moves us into the territory of deciding what is an "appropriately" sized config file, which I'd rather not do. At least we can blame INT_MAX if someone has a too-large config file.
> -Peff
Thanks, Taylor