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  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]
Date:   Fri, 06 Mar 2020 15:58:52 -0600
From: (Eric W. Biederman)
To:     Bernd Edlinger <>
Cc:     Christian Brauner <>,
        Kees Cook <>,
        Jann Horn <>, Jonathan Corbet <>,
        Alexander Viro <>,
        Andrew Morton <>,
        Alexey Dobriyan <>,
        Thomas Gleixner <>,
        Oleg Nesterov <>,
        Frederic Weisbecker <>,
        Andrei Vagin <>,
        Ingo Molnar <>,
        "Peter Zijlstra \(Intel\)" <>,
        Yuyang Du <>,
        David Hildenbrand <>,
        Sebastian Andrzej Siewior <>,
        Anshuman Khandual <>,
        David Howells <>,
        James Morris <>,
        Greg Kroah-Hartman <>,
        Shakeel Butt <>,
        Jason Gunthorpe <>,
        Christian Kellner <>,
        Andrea Arcangeli <>,
        Aleksa Sarai <>,
        "Dmitry V. Levin" <>,
        "linux-doc\" <>,
        "linux-kernel\" <>,
        "linux-fsdevel\" <>,
        "linux-mm\" <>,
        "stable\" <>,
        "linux-api\" <>
Subject: Re: [PATCH 2/2] exec: Add a exec_update_mutex to replace cred_guard_mutex

Bernd Edlinger <> writes:

> On 3/6/20 6:17 AM, Eric W. Biederman wrote:
>> Bernd Edlinger <> writes:
>>> On 3/5/20 10:16 PM, Eric W. Biederman wrote:
>>>> The cred_guard_mutex is problematic.  The cred_guard_mutex is held
>>>> over the userspace accesses as the arguments from userspace are read.
>>>> The cred_guard_mutex is held of PTRACE_EVENT_EXIT as the the other
>>>> threads are killed.  The cred_guard_mutex is held over
>>>> "put_user(0, tsk->clear_child_tid)" in exit_mm().
> I am all for this patch, and the direction it is heading, Eric.
> I just wanted to add a note that I think it is
> possible that exec_mm_release can also invoke put_user(0, tsk->clear_child_tid),
> under the new exec_update_mutex, since vm_access increments the
> mm->mm_users, under the cred_update_mutex, but releases the mutex,
> and the caller can hold the reference for a while and then exec_mmap is not
> releasing the last reference.

Good catch.  I really appreciate your close look at the details.

I am wondering if process_vm_readv and process_vm_writev could be
safely changed to use mmgrab and mmdrop, instead of mmget and mmput.

That would resolve the potential issue you have pointed out.  I just
haven't figured out if it is safe.  The mm code has been seriously
refactored since I knew how it all worked.


Powered by blists - more mailing lists