Skip to content
Browse files

ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME

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: 64b875f ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
Signed-off-by: Jann Horn <>
Acked-by: Oleg Nesterov <>
Signed-off-by: Linus Torvalds <>
  • Loading branch information...
thejh authored and torvalds committed Jul 4, 2019
1 parent 550d1f5 commit 6994eefb0053799d2e07cd140df6c2ea106c41ee
Showing with 1 addition and 3 deletions.
  1. +1 −3 kernel/ptrace.c
@@ -79,9 +79,7 @@ void __ptrace_link(struct task_struct *child, struct task_struct *new_parent,
static void ptrace_link(struct task_struct *child, struct task_struct *new_parent)
__ptrace_link(child, new_parent, __task_cred(new_parent));
__ptrace_link(child, new_parent, current_cred());


0 comments on commit 6994eef

Please sign in to comment.
You can’t perform that action at this time.