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.)
Signed-off-by: Jann Horn <jannh@google.com>
---
Jann Horn (2):
proc: protect ptrace_may_access() with exec_update_lock (part 1)
proc: protect ptrace_may_access() with exec_update_lock (FD links)
fs/proc/array.c | 6 ++
fs/proc/base.c | 159 ++++++++++++++++++++++-----------------------------
fs/proc/fd.c | 27 ++++-----
fs/proc/internal.h | 2 +-
fs/proc/namespaces.c | 12 ++++
5 files changed, 97 insertions(+), 109 deletions(-)
---
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
change-id: 20260518-procfs-lockfix-part1-5dca2d95bc12
--
Jann Horn <jannh@google.com>