This bug allows regular users to put whatever code they want at location zero, and then trick the kernel into executing it. Lovely.
“Since it leads to the kernel executing code at NULL, the vulnerability is as trivial as it can get to exploit,” security researcher Julien Tinnes writes here. “An attacker can just put code in the first page that will get executed with kernel privileges.”
Tinnes and fellow researcher Tavis Ormandy released proof-of-concept code that they said took just a few minutes to adapt from a previous exploit they had. They said all 2.4 and 2.6 version since May 2001 are affected.
Rightly or no, this will blow a big hole in the “Linux is so secure” smugness I often see. Personally, I’ve always thought it was a bad idea to leave user space mapped when you’re in the kernel – for reasons much like this. The model of having completely separate user and kernel/supervisor maps, and special instructions (or instruction variants) to access user space from kernel mode, is less convenient but far more secure.
Linus’s fix doesn’t address the whole class of problems, just this one instance of it. Yes, the kernel should not ever jump to a NULL pointer and any case where that happens should be fixed; but it seems like this bug is likely to recur in some future piece of code and it would be better to defend against this attack in general. Is there any reason to allow a user space process to map address 0? Preventing that seems like a less invasive change than not leaving user space mapped in kernel mode.
Unfortunately, there are applications that do depend on mapping at NULL, to the extent that I think it’s even required by some ABIs. Blech. What I think is insane is that user space is mapped for execute while in the kernel. Unfortunately, the x86 architecture doesn’t support the proper behavior directly, and makes any attempt to emulate it insanely expensive.