commit 8eb43aebcde79ccadf76d80f20d8b3e60663e940
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Tue Jul 23 19:43:18 2019 +0100

    Linux 3.16.71

commit d5d5bd909a4f03f132ee3fd3f6f0568c8344eee5
Author: Jann Horn <jannh@google.com>
Date:   Thu Jul 4 17:32:23 2019 +0200

    ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME
    
    commit 6994eefb0053799d2e07cd140df6c2ea106c41ee upstream.
    
    Fix two issues:
    
    When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU
    reference to the parent's objective credentials, then give that pointer
    to get_cred().  However, the object lifetime rules for things like
    struct cred do not permit unconditionally turning an RCU reference into
    a stable reference.
    
    PTRACE_TRACEME records the parent's credentials as if the parent was
    acting as the subject, but that's not the case.  If a malicious
    unprivileged child uses PTRACE_TRACEME and the parent is privileged, and
    at a later point, the parent process becomes attacker-controlled
    (because it drops privileges and calls execve()), the attacker ends up
    with control over two processes with a privileged ptrace relationship,
    which can be abused to ptrace a suid binary and obtain root privileges.
    
    Fix both of these by always recording the credentials of the process
    that is requesting the creation of the ptrace relationship:
    current_cred() can't change under us, and current is the proper subject
    for access control.
    
    This change is theoretically userspace-visible, but I am not aware of
    any code that it will actually break.
    
    Fixes: 64b875f7ac8a ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
    Signed-off-by: Jann Horn <jannh@google.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>