Meanwhile we have:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...
waiting to be fixed in -stable, which is trivially exploitable.
That's an exploit I'd like to see. So far as I can tell this bug occurs during hardware init,
which for a conventional PCI setup will occur during boot or coldplug. If your hardware is
affected, you should see the kernel try to dereference the NULL pointer at that point,
otherwise, not at all.
Looking at a few examples, this PCI device doesn't seem to come in a hotplug form factor, so a
hotplug exploit will require that you manufacture hardware for the purpose. Few people would
call that "trivial"
Attacking thus during kernel boot is an "airtight hatchway" trick, it gets you privileges to
do something you could already do, and thus isn't a security impact. Coldboot is little
better, you're in userspace, but you're root and even in quite locked down scenarios the root
processes doing coldboot are unrestricted so it's back to the "airtight hatchway".
Posted Jun 17, 2008 13:56 UTC (Tue) by cladisch (✭ supporter ✭, #50193)
[Link]
I did not submit this to -stable because this bug is not in 2.6.25.
"Stable" kernel 2.6.25.7 released
Posted Jun 17, 2008 14:13 UTC (Tue) by PaXTeam (subscriber, #24616)
[Link]
'exploitable' wasn't the best term, interpret it as 'triggerable' instead. other than that,
this code can be compiled as modular and hence loaded a lot later than system boot, it's up to
the sysadmin. in any case, we don't learn whether this potential NULL function pointer deref
occurs while the kernel holds any locks, resources, etc that may cause trouble. do you know
one way or another? that's the point we're trying to make!
PS: we're glad to have learned that at least older kernels aren't affected, would have been
nice to have a word about this in the commit because NULL *function* pointer dereferences
immediately trigger a mental 'look here, it's a potential full kernel compromise' alarm.