linux-toradex.git/fs/exec.c, branch v3.14.3

execve: use 'struct filename *' for executable name passing

2014-02-05T20:54:53+00:00

This changes 'do_execve()' to get the executable name as a 'struct
filename', and to free it when it is done.  This is what the normal
users want, and it simplifies and streamlines their error handling.

The controlled lifetime of the executable name also fixes a
use-after-free problem with the trace_sched_process_exec tracepoint: the
lifetime of the passed-in string for kernel users was not at all
obvious, and the user-mode helper code used UMH_WAIT_EXEC to serialize
the pathname allocation lifetime with the execve() having finished,
which in turn meant that the trace point that happened after
mm_release() of the old process VM ended up using already free'd memory.

To solve the kernel string lifetime issue, this simply introduces
"getname_kernel()" that works like the normal user-space getname()
function, except with the source coming from kernel memory.

As Oleg points out, this also means that we could drop the tcomm[] array
from 'struct linux_binprm', since the pathname lifetime now covers
setup_new_exec().  That would be a separate cleanup.

Reported-by: Igor Zhbanov 
Tested-by: Steven Rostedt 
Cc: Oleg Nesterov 
Cc: Al Viro 
Signed-off-by: Linus Torvalds

fs/exec.c: call arch_pick_mmap_layout() only once

2014-01-24T00:37:02+00:00

Currently both setup_new_exec() and flush_old_exec() issue a call to
arch_pick_mmap_layout().  As setup_new_exec() and flush_old_exec() are
always called pairwise arch_pick_mmap_layout() is called twice.

This patch removes one call from setup_new_exec() to have it only called
once.

Signed-off-by: Richard Weinberger 
Tested-by: Pat Erley 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

exec: avoid propagating PF_NO_SETAFFINITY into userspace child

2014-01-24T00:37:02+00:00

Userspace process doesn't want the PF_NO_SETAFFINITY, but its parent may be
a kernel worker thread which has PF_NO_SETAFFINITY set, and this worker thread
can do kernel_thread() to create the child.
Clearing this flag in usersapce child to enable its migrating capability.

Signed-off-by: Zhang Yi 
Acked-by: Oleg Nesterov 
Cc: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

exec: kill task_struct->did_exec

2014-01-24T00:37:02+00:00

We can kill either task->did_exec or PF_FORKNOEXEC, they are mutually
exclusive.  The patch kills ->did_exec because it has a single user.

Signed-off-by: Oleg Nesterov 
Acked-by: KOSAKI Motohiro 
Cc: Al Viro 
Cc: Kees Cook 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

exec: move the final allow_write_access/fput into free_bprm()

2014-01-24T00:37:02+00:00

Both success/failure paths cleanup bprm->file, we can move this
code into free_bprm() to simlify and cleanup this logic.

Signed-off-by: Oleg Nesterov 
Acked-by: KOSAKI Motohiro 
Cc: Al Viro 
Acked-by: Kees Cook 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

exec:check_unsafe_exec: kill the dead -EAGAIN and clear_in_exec logic

2014-01-24T00:37:02+00:00

fs_struct->in_exec == T means that this ->fs is used by a single process
(thread group), and one of the treads does do_execve().

To avoid the mt-exec races this code has the following complications:

	1. check_unsafe_exec() returns -EBUSY if ->in_exec was
	   already set by another thread.

	2. do_execve_common() records "clear_in_exec" to ensure
	   that the error path can only clear ->in_exec if it was
	   set by current.

However, after 9b1bf12d5d51 "signals: move cred_guard_mutex from
task_struct to signal_struct" we do not need these complications:

	1. We can't race with our sub-thread, this is called under
	   per-process ->cred_guard_mutex. And we can't race with
	   another CLONE_FS task, we already checked that this fs
	   is not shared.

	   We can remove the  dead -EAGAIN logic.

	2. "out_unmark:" in do_execve_common() is either called
	   under ->cred_guard_mutex, or after de_thread() which
	   kills other threads, so we can't race with sub-thread
	   which could set ->in_exec. And if ->fs is shared with
	   another process ->in_exec should be false anyway.

	   We can clear in_exec unconditionally.

This also means that check_unsafe_exec() can be void.

Signed-off-by: Oleg Nesterov 
Acked-by: KOSAKI Motohiro 
Cc: Al Viro 
Cc: Kees Cook 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

exec:check_unsafe_exec: use while_each_thread() rather than next_thread()

2014-01-24T00:37:02+00:00

next_thread() should be avoided, change check_unsafe_exec() to use
while_each_thread().

Nobody except signal->curr_target actually needs next_thread-like code,
and we need to change (fix) this interface.  This particular code is fine,
p == current.  But in general the code like this can loop forever if p
exits and next_thread(t) can't reach the unhashed thread.

This also saves 32 bytes.

Signed-off-by: Oleg Nesterov 
Acked-by: KOSAKI Motohiro 
Cc: Al Viro 
Cc: Kees Cook 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

coredump: make __get_dumpable/get_dumpable inline, kill fs/coredump.h

2014-01-24T00:37:01+00:00

1. Remove fs/coredump.h. It is not clear why do we need it,
   it only declares __get_dumpable(), signal.c includes it
   for no reason.

2. Now that get_dumpable() and __get_dumpable() are really
   trivial make them inline in linux/sched.h.

Signed-off-by: Oleg Nesterov 
Acked-by: Kees Cook 
Cc: Alex Kelly 
Cc: "Eric W. Biederman" 
Cc: Josh Triplett 
Cc: Petr Matousek 
Cc: Vasily Kulikov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

coredump: kill MMF_DUMPABLE and MMF_DUMP_SECURELY

2014-01-24T00:37:01+00:00

Nobody actually needs MMF_DUMPABLE/MMF_DUMP_SECURELY, they are only used
to enforce the encoding of SUID_DUMP_* enum in mm->flags &
MMF_DUMPABLE_MASK.

Now that set_dumpable() updates both bits atomically we can kill them and
simply store the value "as is" in 2 lower bits.

Signed-off-by: Oleg Nesterov 
Acked-by: Kees Cook 
Cc: Alex Kelly 
Cc: "Eric W. Biederman" 
Cc: Josh Triplett 
Cc: Petr Matousek 
Cc: Vasily Kulikov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

coredump: set_dumpable: fix the theoretical race with itself

2014-01-24T00:37:01+00:00

set_dumpable() updates MMF_DUMPABLE_MASK in a non-trivial way to ensure
that get_dumpable() can't observe the intermediate state, but this all
can't help if multiple threads call set_dumpable() at the same time.

And in theory commit_creds()->set_dumpable(SUID_DUMP_ROOT) racing with
sys_prctl()->set_dumpable(SUID_DUMP_DISABLE) can result in SUID_DUMP_USER.

Change this code to update both bits atomically via cmpxchg().

Note: this assumes that it is safe to mix bitops and cmpxchg.  IOW, if,
say, an architecture implements cmpxchg() using the locking (like
arch/parisc/lib/bitops.c does), then it should use the same locks for
set_bit/etc.

Signed-off-by: Oleg Nesterov 
Acked-by: Kees Cook 
Cc: Alex Kelly 
Cc: "Eric W. Biederman" 
Cc: Josh Triplett 
Cc: Petr Matousek 
Cc: Vasily Kulikov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds