We have found an 'interesting interaction' between the gcc compiler and
OpenBSD's inline assembly definition of ntohs().
The resulting bug in the generated assembly causes corrupted data under
the following circumstances:
* The 16-bit value from ntohs() is directly assigned to a 32-bit
variable.
* The 32-bit variable is a local stack variable.
* gcc is set to -march=i686
* OpenBSD 3.8 (gcc 3.3.5)
The attached .tar.gz contains detailed information including test code
and assembly output.
Summary: gcc uses a 16-bit 'movw' instruction to move the ntohs() end
result to the 32-bit stack variable, which leaves the upper 2 bytes of
the 32-bit stack variable uninitialized with random garbage.
The problem was not immediately apparent on Debian Sarge, which also
uses gcc 3.3.5 (but with different default settings, and no pro-police,
etc).
This is probably a bug we need to file with the gcc people, but we want
to give a heads-up to OpenBSD first, and see if this rings a bell here.
(Or yell if we missed something!)
+++chefren
p.s. If the attachment is stripped:
http://idd.nl/test-ntohs.tar.gz
[demime 1.01d removed an attachment of type application/gzip which had a name
of test-ntohs.tar.gz]
