negative memcpy

Rich Felker dalias at aerifal.cx
Tue Aug 9 16:54:06 UTC 2011


On Tue, Aug 09, 2011 at 06:49:58PM +0200, Laurent Bercot wrote:
>  I would guess that the glibc goes out of its way to check that the
> memcpy() arguments are valid and makes a point to crash when they are
> not, with is a safe behaviour but requires extra code, whereas the
> uClibc does not perform such checks, and may crash or may happily
> copy 4 GB of memory all over the place, or fly demons through your nose.

No, I think glibc is correctly treating the argument as unsigned and
looping until it crashes, while uClibc is wrongly treating the
argument as unsigned and copying nothing. This doesn't matter for
sizes like 0xffffffff which are invalid anyway, but it could matter
for sizes like 0x80000000 if uClibc'c malloc allows allocations that
large.

(I'm using 32-bit examples because you can never have allocations
nearly as large as SIZE_MAX on current 64-bit machines.)

Rich


More information about the uClibc mailing list