linux-kernel - Re: [PATCH 1/3] mm: get_cmdline use arg_lock instead of mmap

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190430132403.GG2673@uranus.lan>
Date:   Tue, 30 Apr 2019 16:24:03 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     Michal Koutný <mkoutny@...e.com>
Cc:     Kirill Tkhai <ktkhai@...tuozzo.com>, brgl@...ev.pl,
        arunks@...eaurora.org, geert+renesas@...der.be, mhocko@...nel.org,
        linux-mm@...ck.org, akpm@...ux-foundation.org,
        ldufour@...ux.ibm.com, rppt@...ux.ibm.com, mguzik@...hat.com,
        mkoutny@...e.cz, vbabka@...e.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] mm: get_cmdline use arg_lock instead of mmap_sem

On Tue, Apr 30, 2019 at 12:56:10PM +0200, Michal Koutný wrote:
> On Tue, Apr 30, 2019 at 01:45:17PM +0300, Cyrill Gorcunov <gorcunov@...il.com> wrote:
> > It setups these parameters unconditionally. I need to revisit
> > this moment. Technically (if only I'm not missing something
> > obvious) we might have a race here with prctl setting up new
> > params, but this should be harmless since most of them (except
> > stack setup) are purely informative data.
>
> FTR, when I reviewed that usage, I noticed it was missing the
> synchronization. My understanding was that the mm_struct isn't yet
> shared at this moment. I can see some of the operations take place after
> flush_old_exec (where current->mm = mm_struct), so potentially it is
> shared since then. OTOH, I guess there aren't concurrent parties that
> could access the field at this stage of exec.

Just revisited this code -- we're either executing prctl, either execve.
Since both operates with current task we're safe.