From: Christian Brauner Date: Fri, 22 May 2026 11:49:13 +0000 (+0200) Subject: Merge patch series "proc: protect ptrace_may_access() with exec_update_lock" X-Git-Url: http://git.ipfire.org/gitweb/?a=commitdiff_plain;h=86e9d295084019f4df8ef8e477f39aa42d9a7ef8;p=thirdparty%2Flinux.git Merge patch series "proc: protect ptrace_may_access() with exec_update_lock" Jann Horn 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) --- 86e9d295084019f4df8ef8e477f39aa42d9a7ef8