If neither of those locks is taken during a ptrace_may_access() call, that
is a strong indicator for a security bug where post-execve process
properties can be leaked by racing with execve().
Signed-off-by: Jann Horn <jann@xxxxxxxxx>
---
kernel/ptrace.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 29ace11..17c2245 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -225,6 +225,9 @@ static int __ptrace_may_access(struct task_struct *task, unsigned int mode,
kuid_t caller_uid;
kgid_t caller_gid;
+ WARN_ON(!mutex_is_locked(&task->signal->cred_guard_mutex) &&
+ !mutex_is_locked(&task->signal->cred_guard_light));
+
if (!(mode & PTRACE_MODE_FSCREDS) == !(mode & PTRACE_MODE_REALCREDS)) {
WARN(1, "denying ptrace access check without PTRACE_MODE_*CREDS\n");
return -EPERM;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
