Subject: Re: is this a linux users' FUD spread?
To: Andrew Reilly <andrew-netbsd@areilly.bpc-users.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: current-users
Date: 07/13/2006 07:08:55
--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=
.=20
> > > However, I can't say it bears any resemblance to "our" code.
> >=20
> > But look at fread.c .
>=20
> 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=
=20
(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...
>=20
> 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)
                return (0);

We don't check to see that resid will actually fit in a size_t.

Take care,

Bill

--sdtB3X0nJg68CQEu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEtlP3Wz+3JHUci9cRArv2AJ4yYrkHw2SxZDQPKStkv2juNUUQ/wCfZm0o
m/dxoX+noRmctd8fOXy5uuM=
=dtCp
-----END PGP SIGNATURE-----

--sdtB3X0nJg68CQEu--