Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Linux 2.6.30 exploit posted
Posted Jul 17, 2009 14:24 UTC (Fri) by regala (subscriber, #15745)
Posted Jul 17, 2009 14:39 UTC (Fri) by trasz (guest, #45786)
Posted Jul 17, 2009 14:56 UTC (Fri) by spender (subscriber, #23067)
Posted Jul 17, 2009 15:08 UTC (Fri) by trasz (guest, #45786)
Posted Jul 18, 2009 8:51 UTC (Sat) by Ross (subscriber, #4065)
Posted Jul 18, 2009 16:59 UTC (Sat) by xilun (subscriber, #50638)
The real bug is allowing to map 00000000. This can never be right.
Posted Jul 19, 2009 13:18 UTC (Sun) by PaXTeam (subscriber, #24616)
how else would you be able to run v8086 mode tasks then?
Posted Jul 17, 2009 14:28 UTC (Fri) by Trou.fr (subscriber, #26289)
Posted Jul 17, 2009 20:43 UTC (Fri) by stevenb (guest, #11536)
Posted Jul 17, 2009 17:55 UTC (Fri) by packet (guest, #5202)
Yes, this is a compiler bug.
Posted Jul 18, 2009 14:31 UTC (Sat) by xoddam (subscriber, #2322)
The exploit works because in this case, null is NOT an invalid value, but the compiled code behaves as though it is (and as though the compiler knows how the dereferencing of an invalid value will be handled ... which it doesn't). So yes, it's a compiler bug.
Posted Jul 18, 2009 17:20 UTC (Sat) by xilun (subscriber, #50638)
The platform is defined by the compiler and the runtime. The compiler definitely has the right to consider that dereferencing a NULL pointer is something that is always undefined, because, well, the standard precisely says that. There is no story of mapping or not mapping pages at this point : NULL pointer dereferencing an undefined behavior is, and NULL pointer dereferencing an undefined behavior stays. A NULL pointer has been dereferenced, the behavior is undefined (and it's not very surprising that an undefined behavior as per a standard can be an exploitable security hole). This is as simple as that.
The bug also is in allowing to map address 0, which can't be a sane way to serve a sane purpose.
Posted Jul 18, 2009 22:53 UTC (Sat) by mstefani (subscriber, #31644)
Posted Jul 19, 2009 0:07 UTC (Sun) by xilun (subscriber, #50638)
Posted Jul 19, 2009 8:00 UTC (Sun) by packet (guest, #5202)
Posted Jul 24, 2009 15:39 UTC (Fri) by kubarebo (guest, #59791)
"If all paths to a null pointer test use the same pointer in a memory load/store, then the pointer must have a non-null value at the test. Otherwise, one of the load/stores leading to the test would have faulted."
The assumption that "load/stores [that use the null pointer] [...] would have faulted" is generally wrong.
On many common architectures, virtual memory location 0 can be mapped and used. Most "small" embedded platforms allow its use. x86 surely does, too.
I think that the optimization was relatively ill conceived. The memory load/store should not be assumed to fail unless the underlying architecture universally guarantees that, or at least the target does. In this case, the target definitely does not guarantee anything of the sort, and the optimization is simply broken. I don't think theres much more to that. As a workaround, all linux kernel builds should disable the particular optimization (if possible).
I deal daily with code where the compiled C code dereferences NULL pointers simply because the underlying architecture supports it, and not letting you do it wastes one byte/word of RAM. On chips with only 256 bytes of RAM you may not want that. On x86 in real mode, the IDT starts at address 0 and some odd tasks like copying the IDT have to start at 0.
Methinks that the NULL pointer concept should be purged from the C standard, it is really up to the developer to ensure that a pointer is valid, and using magic values to indicate invalid pointers is very much environment-dependent. It has no place in a rather platform-agnostic language standard, IMHO.
Posted Jul 24, 2009 20:44 UTC (Fri) by nix (subscriber, #2304)
The C Standard disagrees that it's up to the developer to ensure a pointer
is valid: it doesn't just ban null pointers but also things like dividing
pointers by two, XORing pointers, shoving pointers off the ends of arrays
and so on. Attempting to dictate the semantics of pointers in these
situations would be catastrophic for optimization: even simple code motion
would probably have to be banned.
A simple flag (and a target flag) that says 'this compilation
specifically/this target usually has nonfaulting accesses to (void *)0' is
all that's needed, and we have that already.
Posted Apr 13, 2011 17:23 UTC (Wed) by Blaisorblade (guest, #25465)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds