Re: [patch 0/6] lightweight robust futexes: -V3

Ingo Molnar
2006-02-16T21:37:23Z

* Paul Jackson <pj@sgi.com> wrote:

> That malicious code would have no need to have the kernel futext
> handling code do its dirty work indirectly via manipulations of this
> list. It can just do the dirty work directly.
>
> All Ingo needs to insure is that the kernel will assume no more
> priviledge when reading/writing this list than the current task had,
> from user space, reading/writing this list.

Correct, this is precisely what happens.

Furthermore, the new exit-time futex code within the kernel will do only
one, very limited thing with userspace memory: it will atomically set
bit 30 of a word at a userspace address (if the word is accessible to
and writable by userspace), if and only if that word is equal to
current->pid. This is really not the sort of memory writing capability
attackers are looking for :-)

Btw., we already have a similar mechanism in the kernel (and had for
years): the current->clear_child_tid pointer will be overwritten with 0
by the kernel at do_exit() time, and causes a futex wakeup. See
kernel/fork.c:mm_release():

if (tsk->clear_child_tid && atomic_read(&mm->mm_users) > 1) {
u32 __user * tidptr = tsk->clear_child_tid;
tsk->clear_child_tid = NULL;

/*
* We don't check the error code - if userspace has
* not set up a proper pointer then tough luck.
*/
put_user(0, tidptr);
sys_futex(tidptr, FUTEX_WAKE, 1, NULL, NULL, 0);

So the concept is not unprecedented at all, nor did it ever cause any
security problems [and i think i'd know - i wrote the above code too].
And 'write 0' is slightly more interesting to attackers than 'set bit 30
if word equals to TID'.

Ingo