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@xxxxxxxxxxxxxxxxxxx .

> 
> 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@xxxxxxxxxxxxxxxxxx .
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.