[PATCH] umh: fix memory leak on execve failure

[PATCH] umh: fix memory leak on execve failure

[Vincent Minet]

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

Re: [PATCH] umh: fix memory leak on execve failure

[Jakub Kicinski]

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!

[PATCH] umh: fix memory leak on execve failure

[Vincent Minet]

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

Re: [PATCH] umh: fix memory leak on execve failure

[Vincent Minet]

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

Re: [PATCH] umh: fix memory leak on execve failure

[Tetsuo Handa]

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.