Re: [PATCH 6/6] config: reject parsing of files over INT_MAX

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Apr 10, 2020 at 06:15:49PM -0400, Jeff King wrote:
> On Fri, Apr 10, 2020 at 03:04:31PM -0700, Junio C Hamano wrote:
>
> > Jeff King <peff@xxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux