If a UMH process created by fork_usermode_blob() fails to execute, a pair of struct file allocated by umh_pipe_setup() will leak. Under normal conditions, the caller (like bpfilter) needs to manage the lifetime of the UMH and its two pipes. But when fork_usermode_blob() fails, the caller doesn't really have a way to know what needs to be done. It seems better to do the cleanup ourselves in this case. Fixes: 449325b52b7a ("umh: introduce fork_usermode_blob() helper") Signed-off-by: Vincent Minet <v.minet@criteo.com> --- kernel/umh.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/umh.c b/kernel/umh.c index 7f255b5a8845..20d51e0957e0 100644 --- a/kernel/umh.c +++ b/kernel/umh.c @@ -475,6 +475,12 @@ static void umh_clean_and_save_pid(struct subprocess_info *info) { struct umh_info *umh_info = info->data; + /* cleanup if umh_pipe_setup() was successful but exec failed */ + if (info->pid && info->retval) { + fput(umh_info->pipe_to_umh); + fput(umh_info->pipe_from_umh); + } + argv_free(info->argv); umh_info->pid = info->pid; } -- 2.26.0
In my case, execve fails with ENOENT on a Tomoyo enabled kernel. It doesn't seem like CONFIG_BPFILTER and CONFIG_SECURITY_TOMOYO are compatible as it is. The UMH is executed via "do_execve_file", so we'll have bprm->filename set to "none". This causes the following call chain to fail and search_binary_handler() to return ENOENT. search_binary_handler() -> security_bprm_check() -> tomoyo_bprm_check_security() -> tomoyo_find_next_domain() -> tomoyo_realpath_nofollow() I don't really know how to solve this. As I understand it, you really need a "valid" pathname for Tomoyo and it's not obvious what that should be for the user-mode blob. -- Vincent Minet
Hello. On 2020/04/14 0:49, Vincent Minet wrote: > In my case, execve fails with ENOENT on a Tomoyo enabled kernel. It doesn't seem > like CONFIG_BPFILTER and CONFIG_SECURITY_TOMOYO are compatible as it is. Thanks for the report. Yes, I know this is a potential problem since 3.19 and this is a practical problem since 4.18, as explained at https://lkml.kernel.org/r/f8099e95-c0fc-d133-471e-e0ba97d2230e@i-love.sakura.ne.jp . > > The UMH is executed via "do_execve_file", so we'll have bprm->filename set to > "none". This causes the following call chain to fail and search_binary_handler() > to return ENOENT. > search_binary_handler() -> > security_bprm_check() -> > tomoyo_bprm_check_security() -> > tomoyo_find_next_domain() -> > tomoyo_realpath_nofollow() > > I don't really know how to solve this. As I understand it, you really need > a "valid" pathname for Tomoyo and it's not obvious what that should be for the > user-mode blob. It seems that Al wants to change __do_execve_file(), as commented at https://lkml.kernel.org/r/20200329031702.GB23230@ZenIV.linux.org.uk . Bringing tomoyo_realpath_nofollow() to __do_execve_file() (in other words, solve AT_SYMLINK_NOFOLLOW path and !AT_SYMLINK_NOFOLLOW path at the same time) will be the right (from the perspective of race-free) solution. But I don't know an API that allows resolving !AT_SYMLINK_NOFOLLOW path starting from AT_SYMLINK_NOFOLLOW path. I need to wait for Al, for I can't implement race-free solution from TOMOYO side.
If a UMH process created by fork_usermode_blob() fails to execute, a pair of struct file allocated by umh_pipe_setup() will leak. Under normal conditions, the caller (like bpfilter) needs to manage the lifetime of the UMH and its two pipes. But when fork_usermode_blob() fails, the caller doesn't really have a way to know what needs to be done. It seems better to do the cleanup ourselves in this case. Fixes: 449325b52b7a ("umh: introduce fork_usermode_blob() helper") Signed-off-by: Vincent Minet <v.minet@criteo.com> --- kernel/umh.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/umh.c b/kernel/umh.c index 7f255b5a8845..20d51e0957e0 100644 --- a/kernel/umh.c +++ b/kernel/umh.c @@ -475,6 +475,12 @@ static void umh_clean_and_save_pid(struct subprocess_info *info) { struct umh_info *umh_info = info->data; + /* cleanup if umh_pipe_setup() was successful but exec failed */ + if (info->pid && info->retval) { + fput(umh_info->pipe_to_umh); + fput(umh_info->pipe_from_umh); + } + argv_free(info->argv); umh_info->pid = info->pid; } -- 2.26.2
On Fri, 8 May 2020 00:14:22 +0200 Vincent Minet wrote:
> If a UMH process created by fork_usermode_blob() fails to execute,
> a pair of struct file allocated by umh_pipe_setup() will leak.
>
> Under normal conditions, the caller (like bpfilter) needs to manage the
> lifetime of the UMH and its two pipes. But when fork_usermode_blob()
> fails, the caller doesn't really have a way to know what needs to be
> done. It seems better to do the cleanup ourselves in this case.
>
> Fixes: 449325b52b7a ("umh: introduce fork_usermode_blob() helper")
> Signed-off-by: Vincent Minet <v.minet@criteo.com>
Applied to net, thank you!