On Sun 19 July 2009 10:33:00 am Lisa Kachold wrote: > This code looks perfectly acceptable, right? Well, it is, until the > compiler takes this into its hands. While optimizing the code, the > compiler will see that the variable has already been assigned and will > actually remove the if block (the check if tun is NULL) completely > from the resulting compiled code. In other words, the compiler will > introduce the vulnerability to the binary code, which didn't exist in > the source code. This will cause the kernel to try to read/write data > from 0x00000000, which the attacker can map to userland – and this > finally pwns the box No, it reads from (NULL+offsetof(sk)) Doing pointer arithetic on NULL is perfectly legal (but not dereferencing NULL), and basically that's what this relies on. sk = tun->sk; is the same as writing sk = *(&tun+offsetof(sk)); // idk what that offset is, let's say it's 42 bytes which, in the case would be dereferencing (0x00000000+0x00000042) which is perfectly legal and accessible memory. Therein lies the problem. Some say it is a problem with the compiler optimisation, some say it's a kernel bug. Both should be fixed, imo. Ryan -- --- Ryan Rix (623)-826-0051 The problem here (as someon else stated) is that when multiple dists use the same package format it only gives a "false sense of compatibility". -- Stephen Carpenter http://hackersramblings.wordpress.com | http://twitter.com/phrkonaleash XMPP: phrkonaleash@gmail.com | MSN: phrkonaleash@yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh@irc.freenode.net/#srcedit,#teensonlinux,#plugaz and countless other FOSS channels.