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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <a4cd5557-2466-7826-bf82-5d91ff96a13c@i-love.sakura.ne.jp>
Date:   Tue, 14 Apr 2020 07:56:42 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Vincent Minet <v.minet@...teo.com>
Cc:     linux-kernel@...r.kernel.org, Luis Chamberlain <mcgrof@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] umh: fix memory leak on execve failure

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.