linux-toradex.git/kernel/kmod.c, branch v3.15-rc6

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

kernel/kmod.c: check for NULL in call_usermodehelper_exec()

2013-09-30T21:31:02+00:00

If /proc/sys/kernel/core_pattern contains only "|", a NULL pointer
dereference happens upon core dump because argv_split("") returns
argv[0] == NULL.

This bug was once fixed by commit 264b83c07a84 ("usermodehelper: check
subprocess_info->path != NULL") but was by error reintroduced by commit
7f57cfa4e2aa ("usermodehelper: kill the sub_info->path[0] check").

This bug seems to exist since 2.6.19 (the version which core dump to
pipe was added).  Depending on kernel version and config, some side
effect might happen immediately after this oops (e.g.  kernel panic with
2.6.32-358.18.1.el6).

Signed-off-by: Tetsuo Handa 
Acked-by: Oleg Nesterov 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

usermodehelper: kill the sub_info->path[0] check

2013-07-03T23:08:02+00:00

call_usermodehelper_exec() does nothing but returns success if path[0] ==
0.  The only user which needs this strange feature is request_module(), it
can check modprobe_path[0] itself like other users do if they want to
detect the "disabled by admin" case.

Kill it.  Not only it looks strange, it can confuse other callers.  And
this allows us to revert 264b83c0 ("usermodehelper: check
subprocess_info->path != NULL"), do_execve(NULL) is safe.

Signed-off-by: Oleg Nesterov 
Acked-by: Rusty Russell 
Cc: Lucas De Marchi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

usermodehelper: check subprocess_info->path != NULL

2013-05-16T19:01:11+00:00

argv_split(empty_or_all_spaces) happily succeeds, it simply returns
argc == 0 and argv[0] == NULL. Change call_usermodehelper_exec() to
check sub_info->path != NULL to avoid the crash.

This is the minimal fix, todo:

 - perhaps we should change argv_split() to return NULL or change the
   callers.

 - kill or justify ->path[0] check

 - narrow the scope of helper_lock()

Signed-off-by: Oleg Nesterov 
Acked-By: Lucas De Marchi 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds

kmod: remove call_usermodehelper_fns()

2013-05-01T00:04:06+00:00

This function suffers from not being able to determine if the cleanup is
called in case it returns -ENOMEM.  Nobody is using it anymore, so let's
remove it.

Signed-off-by: Lucas De Marchi 
Cc: Oleg Nesterov 
Cc: David Howells 
Cc: James Morris 
Cc: Al Viro 
Cc: Tejun Heo 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kmod: split call to call_usermodehelper_fns()

2013-05-01T00:04:06+00:00

Use call_usermodehelper_setup() + call_usermodehelper_exec() instead of
calling call_usermodehelper_fns().  In case the latter returns -ENOMEM the
cleanup function may had not been called - in this case we would not free
argv and module_name.

Signed-off-by: Lucas De Marchi 
Cc: Oleg Nesterov 
Cc: David Howells 
Cc: James Morris 
Cc: Al Viro 
Cc: Tejun Heo 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

usermodehelper: export call_usermodehelper_exec() and call_usermodehelper_setup()

2013-05-01T00:04:05+00:00

call_usermodehelper_setup() + call_usermodehelper_exec() need to be
called instead of call_usermodehelper_fns() when the cleanup function
needs to be called even when an ENOMEM error occurs.  In this case using
call_usermodehelper_fns() the user can't distinguish if the cleanup
function was called or not.

[akpm@linux-foundation.org: export call_usermodehelper_setup() to modules]
Signed-off-by: Lucas De Marchi 
Reviewed-by: Oleg Nesterov 
Cc: David Howells 
Cc: James Morris 
Cc: Al Viro 
Cc: Tejun Heo 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'master' into for-3.9-async

2013-01-23T17:31:01+00:00

To receive f56c3196f251012de9b3ebaff55732a9074fdaae ("async: fix
__lowest_in_progress()").

Signed-off-by: Tejun Heo

async, kmod: warn on synchronous request_module() from async workers

2013-01-23T00:48:03+00:00

Synchronous requet_module() from an async worker can lead to deadlock
because module init path may invoke async_synchronize_full().  The
async worker waits for request_module() to complete and the module
loading waits for the async task to finish.  This bug happened in the
block layer because of default elevator auto-loading.

Block layer has been updated not to do default elevator auto-loading
and it has been decided to disallow synchronous request_module() from
async workers.

Trigger WARN_ON_ONCE() on synchronous request_module() from async
workers.

For more details, please refer to the following thread.

  http://thread.gmane.org/gmane.linux.kernel/1420814

Signed-off-by: Tejun Heo 
Reported-by: Alex Riesen 
Cc: Linus Torvalds 
Cc: Arjan van de Ven

Bury the conditionals from kernel_thread/kernel_execve series

2012-12-19T23:07:38+00:00

All architectures have
	CONFIG_GENERIC_KERNEL_THREAD
	CONFIG_GENERIC_KERNEL_EXECVE
	__ARCH_WANT_SYS_EXECVE
None of them have __ARCH_WANT_KERNEL_EXECVE and there are only two callers
of kernel_execve() (which is a trivial wrapper for do_execve() now) left.
Kill the conditionals and make both callers use do_execve().

Signed-off-by: Al Viro