do_execve() must not clear fs->in_exec if it was set by another thread
authorOleg Nesterov <oleg@redhat.com>
Thu, 23 Apr 2009 23:01:56 +0000 (01:01 +0200)
committerLinus Torvalds <torvalds@linux-foundation.org>
Fri, 24 Apr 2009 14:39:45 +0000 (07:39 -0700)
commit8c652f96d3852b97a49c331cd0bb02d22f3cb31b
tree9752969f2ae7312026bb4037ecd950dafd403d9b
parent091069740304c979f957ceacec39c461d0192158
do_execve() must not clear fs->in_exec if it was set by another thread

If do_execve() fails after check_unsafe_exec(), it clears fs->in_exec
unconditionally. This is wrong if we race with our sub-thread which
also does do_execve:

Two threads T1 and T2 and another process P, all share the same
->fs.

T1 starts do_execve(BAD_FILE). It calls check_unsafe_exec(), since
->fs is shared, we set LSM_UNSAFE but not ->in_exec.

P exits and decrements fs->users.

T2 starts do_execve(), calls check_unsafe_exec(), now ->fs is not
shared, we set fs->in_exec.

T1 continues, open_exec(BAD_FILE) fails, we clear ->in_exec and
return to the user-space.

T1 does clone(CLONE_FS /* without CLONE_THREAD */).

T2 continues without LSM_UNSAFE_SHARE while ->fs is shared with
another process.

Change check_unsafe_exec() to return res = 1 if we set ->in_exec, and change
do_execve() to clear ->in_exec depending on res.

When do_execve() suceeds, it is safe to clear ->in_exec unconditionally.
It can be set only if we don't share ->fs with another process, and since
we already killed all sub-threads either ->in_exec == 0 or we are the
only user of this ->fs.

Also, we do not need fs->lock to clear fs->in_exec.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Roland McGrath <roland@redhat.com>
Acked-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/compat.c
fs/exec.c