| |||||||||||||
|
| |||||||||||||
Linux 2.6.30 exploit postedLinux 2.6.30 exploit postedPosted Jul 17, 2009 14:24 UTC (Fri) by regala (subscriber, #15745)In reply to: Linux 2.6.30 exploit posted by trasz Parent article: Linux 2.6.30 exploit posted
no, you don't understand. this pointer should not be NULL, and having it NULL in the code executed after the check is the security matter. Thus, the exploit has first to cause this ptr to be NULL, and it has to rely on the fact that gcc wrongly moves this check away assuming it is not necessary, being done after dereferencing the pointer, which may be wrong in certain loads, or in SMP, preemptible configs.
(Log in to post comments)
Linux 2.6.30 exploit posted Posted Jul 17, 2009 14:39 UTC (Fri) by trasz (guest, #45786) [Link]
This code wouldn't be valid in SMP or in preemptible kernel either, unless some locking was added, which would completely change the situation and would probably prevent the problematic optimization from being applied. Other possible way would be to make the variable volatile. Anyway, this is a programming error.
Linux 2.6.30 exploit posted Posted Jul 17, 2009 14:56 UTC (Fri) by spender (subscriber, #23067) [Link]
Well, since my videos show me exploiting the bug on multiple SMP and preemptible kernels, that's false. If you would read the exploit source you'd see this.
-Brad
Linux 2.6.30 exploit posted Posted Jul 17, 2009 15:08 UTC (Fri) by trasz (guest, #45786) [Link]
Erm, let me restate what I've written above - the kernel code mentioned above wouldn't be valid in any case, including SMP and preemptible kernel, contrary to what Regala said in the comment before.
Linux 2.6.30 exploit posted Posted Jul 18, 2009 8:51 UTC (Sat) by Ross (subscriber, #4065) [Link]
There is no point in checking if it is NULL _after_ you have used it. As soon as you have dereferenced a NULL pointer you can't predict what the program will do, and there is no point in blaming the compiler about it. GCC doesn't claim to allow this and it is not required to by any of the C standards.
Linux 2.6.30 exploit posted Posted Jul 18, 2009 16:59 UTC (Sat) by xilun (subscriber, #50638) [Link]
Given this source code, gcc has all rights to remove the check, and you obviously don't understand what do and does not imply concurrency, SMP, and preemptible configs.
The real bug is allowing to map 00000000. This can never be right.
Linux 2.6.30 exploit posted Posted Jul 19, 2009 13:18 UTC (Sun) by PaXTeam (subscriber, #24616) [Link]
> The real bug is allowing to map 00000000. This can never be right.
how else would you be able to run v8086 mode tasks then?
|
|
||||||||||||