summaryrefslogtreecommitdiffstats
path: root/kernel/fork.c
diff options
context:
space:
mode:
authorVasiliy Kulikov2011-07-27 01:08:38 +0200
committerLinus Torvalds2011-07-27 01:49:43 +0200
commit293eb1e7772b25a93647c798c7b89bf26c2da2e0 (patch)
treedebd49012773091732ee1e1b2388462b759525a7 /kernel/fork.c
parentprocfs: return ENOENT on opening a being-removed proc entry (diff)
downloadkernel-qcow2-linux-293eb1e7772b25a93647c798c7b89bf26c2da2e0.tar.gz
kernel-qcow2-linux-293eb1e7772b25a93647c798c7b89bf26c2da2e0.tar.xz
kernel-qcow2-linux-293eb1e7772b25a93647c798c7b89bf26c2da2e0.zip
proc: fix a race in do_io_accounting()
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> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'kernel/fork.c')
0 files changed, 0 insertions, 0 deletions