We tracked this down off-list.
Given these types:
char *buf;
uint len;
gcc-4.2 assumes that buf+len >= buf.
The test for wraparound when computing len in sprint looks like:
len = 1<<30; /* big number, but sprint is deprecated anyway */
/*
* on PowerPC, the stack is near the top of memory, so
* we must be sure not to overflow a 32-bit pointer.
*/
if(buf+len < buf)
len = -(uintptr)buf-1;
gcc-4.2 compiles this away. Adding some uintptr casts
works around the problem. This change is checked
into the plan9port code and will be in tomorrows tar file.
Because David is running 32-bit code on a 64-bit kernel,
the stack is near the very top of 32-bit address space
and tickles the gcc-4.2 bug.
It would not surprise me if there are some exploitable
buffer overflows (in standard code, not p9p) now that
gcc is silently discarding checks like this one.
Russ
