Fix unlikely (but possible) race condition on task->user access
authorLinus Torvalds <torvalds@g5.osdl.org>
Sat, 4 Nov 2006 18:06:02 +0000 (10:06 -0800)
committerLinus Torvalds <torvalds@g5.osdl.org>
Sat, 4 Nov 2006 18:06:02 +0000 (10:06 -0800)
commit45c18b0bb579b5c1b89f8c99f1b6ffa4c586ba08
tree2dbd334c763232ce2de46739908054639e5629c8
parent80491eb90c750fcd7d13830062f27ae9b7cc5f75
Fix unlikely (but possible) race condition on task->user access

There's a possible race condition when doing a "switch_uid()" from one
user to another, which could race with another thread doing a signal
allocation and looking at the old thread ->user pointer as it is freed.

This explains an oops reported by Lukasz Trabinski:
http://permalink.gmane.org/gmane.linux.kernel/462241

We fix this by delaying the (reference-counted) freeing of the user
structure until the thread signal handler lock has been released, so
that we know that the signal allocation has either seen the new value or
has properly incremented the reference count of the old one.

Race identified by Oleg Nesterov.

Cc: Lukasz Trabinski <lukasz@wsisiz.edu.pl>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
kernel/user.c