提交 45c18b0b 编写于 作者: L Linus Torvalds

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: NLinus Torvalds <torvalds@osdl.org>
上级 80491eb9
...@@ -187,6 +187,17 @@ void switch_uid(struct user_struct *new_user) ...@@ -187,6 +187,17 @@ void switch_uid(struct user_struct *new_user)
atomic_dec(&old_user->processes); atomic_dec(&old_user->processes);
switch_uid_keyring(new_user); switch_uid_keyring(new_user);
current->user = new_user; current->user = new_user;
/*
* We need to synchronize with __sigqueue_alloc()
* doing a get_uid(p->user).. If that saw the old
* user value, we need to wait until it has exited
* its critical region before we can free the old
* structure.
*/
smp_mb();
spin_unlock_wait(&current->sighand->siglock);
free_uid(old_user); free_uid(old_user);
suid_keys(current); suid_keys(current);
} }
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册