Re: [Bug-gnulib] checking for overflow

[Bruno Haible]

Jim Meyering wrote:
> You may have seen the one regarding a recently-fixed bug in `ls -C -w N'.
> For some large values of N, ls would hit an address overflow
> bug and segfault.

And for some not-so-large values of N, such as 60000, ls will allocate
700 MB of memory. Which also allows some kind of denial-of-service attack.
Therefore in this case I would blame the apparently quadratic memory
consumption, together with the ability to pass an arbitrary ls option
via ftpd.

Please don't understand me wrong: I don't want to blame 'ls'. (gperf too
has quadratic memory consumption.)

I only wish to know whether each time I malloc() a pathname, let's say, to add
a suffix to an existing pathname, I need to check for size_t overflow.
The answer will likely be "no". Then I'd like to know which criteria can
be used to decide this.

For multiplications, it seems clear that checking is required.

For multiplication by 2: can we rely on malloc() failing for sizes between
2 GB and 4 GB? If so, it would mean we'll get a malloc failure before the
size_t overflow.

For addition?

Bruno