]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
Merge patch series "proc: protect ptrace_may_access() with exec_update_lock"
authorChristian Brauner <brauner@kernel.org>
Fri, 22 May 2026 11:49:13 +0000 (13:49 +0200)
committerChristian Brauner <brauner@kernel.org>
Fri, 5 Jun 2026 08:00:55 +0000 (10:00 +0200)
commit86e9d295084019f4df8ef8e477f39aa42d9a7ef8
tree03a43424fca41ffbb0e2b304be927aad8089727c
parenta76640171b29fc91b9777a8e1bdc7e08db697275
parent6255da28d4bb5349fe18e84cb043ccd394eba75d
Merge patch series "proc: protect ptrace_may_access() with exec_update_lock"

Jann Horn <jannh@google.com> says:

My understanding is that procfs is effectively maintained by the VFS
maintainers (though scripts/get_maintainer.pl claims that there are
no maintainers for procfs because the VFS entry only claims files
directly in fs/, and the procfs entry has no maintainers listed on
it).

In procfs, most uses of ptrace_may_access() should use
exec_update_lock to avoid TOCTOU issues with concurrent privileged
execve() (like setuid binary execution).

This series doesn't fix all the remaining issues in procfs, but it fixes
the easy cases for now; I will probably follow up with fixes for the
gnarlier cases later unless someone else wants to do that.

I have checked that procfs files still work with these changes and that
CONFIG_PROVE_LOCKING=y doesn't generate any warnings.

(checkpatch complains about missing argument names in
proc_op::proc_get_link, but that was already the case before my patch.)

* patches from https://patch.msgid.link/20260518-procfs-lockfix-part1-v1-0-5c3d20e0ac33@google.com:
  proc: protect ptrace_may_access() with exec_update_lock (FD links)
  proc: protect ptrace_may_access() with exec_update_lock (part 1)

Link: https://patch.msgid.link/20260518-procfs-lockfix-part1-v1-0-5c3d20e0ac33@google.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>