| |||||||||||||
Linux 2.6.30 exploit postedLinux 2.6.30 exploit postedPosted Jul 17, 2009 14:36 UTC (Fri) by epa (subscriber, #39769)In reply to: Linux 2.6.30 exploit posted by Ajaxelitus Parent article: Linux 2.6.30 exploit posted
So why is this assumption true for userspace code but unsound when running in the kernel?
(Log in to post comments)
Linux 2.6.30 exploit posted Posted Jul 17, 2009 14:44 UTC (Fri) by trasz (guest, #45786) [Link]
Userspace code would get SEGV signal due to null pointer dereference and probably exit. Pretty much any kernel other than Linux would panic and restart. In Linux there is this strange "Oops" mechanism inspired probably by Windows 95, which makes the kernel try to continue. I've got an impression that it would make the code exit somehow instead of continuing past the null check that got optimized away, though.
Linux 2.6.30 exploit posted Posted Jul 17, 2009 15:11 UTC (Fri) by hegel (guest, #49501) [Link]
Oops mechanism doesn't try to continue either - it kills the current process most of the time (See http://www.faqs.org/docs/Linux-HOWTO/Kernel-HOWTO.html#AE...). The exploit does mmap(NULL, MAP_FIXED) - that's why it doesn't crash..
Linux 2.6.30 exploit posted Posted Jul 18, 2009 9:11 UTC (Sat) by Ross (subscriber, #4065) [Link]
Yes that's the usual response. But the compiler can apply the same logic in userspace and there are ways to make NULL dereferences not crash (installation of a SEGV signal handler, mapping something to page zero).
In any case, it's not like this would be a good idea for userspace code. If you care enough to check if a pointer is NULL, it should really be done before dereferencing it, otherwise it is too late to stop any undefined behavior. Even if you can be sure an implementation will just crash the program, what's the point of adding code afterwards which isn't reachable?
|
|||||||||||||