proc: fix a race in do_io_accounting()
authorVasiliy Kulikov <segoon@openwall.com>
Tue, 26 Jul 2011 23:08:38 +0000 (16:08 -0700)
committerGreg Kroah-Hartman <gregkh@suse.de>
Fri, 5 Aug 2011 04:58:40 +0000 (21:58 -0700)
commit8cd3f19d8310dd5086f396f78d9b5bcf459f6e81
treea933d4311d6d73a75e7b238ad4a36ea00d209c60
parentc14acb19a4b1482b6dd6e9d0874b2c8e32d6599d
proc: fix a race in do_io_accounting()

commit 293eb1e7772b25a93647c798c7b89bf26c2da2e0 upstream.

If an inode's mode permits opening /proc/PID/io and the resulting file
descriptor is kept across execve() of a setuid or similar binary, the
ptrace_may_access() check tries to prevent using this fd against the
task with escalated privileges.

Unfortunately, there is a race in the check against execve().  If
execve() is processed after the ptrace check, but before the actual io
information gathering, io statistics will be gathered from the
privileged process.  At least in theory this might lead to gathering
sensible information (like ssh/ftp password length) that wouldn't be
available otherwise.

Holding task->signal->cred_guard_mutex while gathering the io
information should protect against the race.

The order of locking is similar to the one inside of ptrace_attach():
first goes cred_guard_mutex, then lock_task_sighand().

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fs/proc/base.c