Now that all machines out there are fixed and save of this
particular exploit :-) can anyone of you describe *exactly*
what this exploit does? I've been looking at the code
(mm/mm.c, around line 1045) for some time now and I can't
quite figure it out.
I'd like to quote Isaac To from debian-devel:
> Actually I'm staring at the code for hours without much success about how to
> write anything in the kernel. It does not literally allow access to the
> kernel address space: if it does so, all you need to do is to traverse the
> kernel data structures to find where is the task_struct for the process
> itself and change the EUID to 0 in order to get root. What the bug gives is
> a memory region that extends through the kernel memory. The process cannot
> access that region: it is protected, and you can read it only in kernel
> mode. You cannot try to pass that as an address buffer to a system call
> either: system calls check whether address is past the end of process
> address space. So the program must somehow trick the kernel into accessing
> the region by itself, and since the kernel believes the correctness of the
> region it will not do any further checking. The only way that readily comes
> to mind is to let the program core dump: the kernel will most likely happily
> read all the kernel memory and save it into the core file. But it is still
> rather far from changing anything in the kernel memory. Andreas is
> definitely right that the hole doesn't look like that it is that dangerous.
Has anyone got more information?