Subject: Re: is this a linux users' FUD spread?
To: Andrew Reilly <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 07/13/2006 07:08:55
Content-Type: text/plain; charset=us-ascii
On Fri, Jul 07, 2006 at 11:19:55AM +1000, Andrew Reilly wrote:
> On Thu, Jul 06, 2006 at 11:45:13PM +0200, Pavel Cahyna wrote:
> > On Thu, Jul 06, 2006 at 08:44:54PM +0000, Martijn van Buul wrote:
> > > It came back. That code segment *does* seem kind of nasty, and does
> > > seem to assume that "size_t" and "unsigned" have the same word length=
> > > However, I can't say it bears any resemblance to "our" code.
> > But look at fread.c .
> What are we looking at in fread.c? I see no unsigned there, and
> the code all looks quite careful.
It's easier to understand if you look at the advisory:
How To Detect The Defect
In the calloc case, the source code should be examined. Constructs like=20
size =3D count * element_size; without any overflow checks are problematic=
(and, similarly, expressions like size *=3D nelems).
> Hmm. No, the range check on the size_t size argument to setvbuf()
> is wrong: (int)size < 0, rather than size < INT_MAX, so
> there's some possibility that a user-supplied buffer could be
> incorrectly under-utilized on a system with 64-bit size_t...
> I don't think that's an error in fread.c per se, though.
There is one, though we probably won't hit it.
if ((resid =3D count * size) =3D=3D 0)
We don't check to see that resid will actually fit in a size_t.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----