[Top][All Lists]

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

Re: [Bug-gnulib] checking for overflow

From: Bruno Haible
Subject: Re: [Bug-gnulib] checking for overflow
Date: Mon, 20 Oct 2003 17:48:26 +0200
User-agent: KMail/1.5

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]