Files
linux/include/linux
Linus Torvalds 9c9e6bd4cc Merge tag 'kernel-7.2-rc1.task_exec_state' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull task_exec_state updates from Christian Brauner:
 "This introduces a new per-task task_exec_state structure and relocates
  the dumpable mode and the user namespace captured at execve() from
  mm_struct onto it. It stays attached to the task for its full
  lifetime.

  __ptrace_may_access() and several /proc owner and visibility checks
  need to consult two pieces of state for any observable task, including
  zombies that have already gone through exit_mm(): the dumpable mode
  and the user namespace captured at execve(). Both live on mm_struct
  today, which exit_mm() clears from the task long before the task is
  reaped. A reader that races with do_exit() observes task->mm == NULL
  and either fails the check or falls back to init_user_ns - which
  denies legitimate access to non-dumpable zombies that were running in
  a nested user namespace.

  mm_struct loses ->user_ns and the dumpability bits in ->flags.
  MMF_DUMPABLE_BITS is reserved so the MMF_DUMP_FILTER_* layout exposed
  via /proc/<pid>/coredump_filter stays stable. task->user_dumpable and
  its exit_mm() snapshot are removed.

  task_exec_state is the privilege domain established by an execve().
  Within a thread group it is shared via refcount; across thread groups
  each task has its own:

   - CLONE_VM siblings (thread-group members, io_uring workers)
     refcount-share the parent's exec_state.

   - Non-CLONE_VM clones (fork(), vfork() without CLONE_VM) allocate a
     fresh exec_state inheriting the parent's dumpable mode and user_ns.

   - execve() in the child allocates a fresh instance and installs it
     under task_lock + exec_update_lock via task_exec_state_replace().

   - Credential changes (setresuid, capset, ...) and
     prctl(PR_SET_DUMPABLE) update dumpability on the current task's
     exec_state, i.e., on the thread group's shared instance.

  On top of this exec_mmap() no longer tears down the old mm while
  holding exec_update_lock for writing and cred_guard_mutex. Neither
  lock is needed for that: exec_update_lock only exists to make the mm
  swap atomic with the later commit_creds() and all its readers operate
  on the new mm; none looks at the detached old mm.

  The cost was real: __mmput() runs exit_mmap() over the entire old
  address space and can block in exit_aio() waiting for in-flight AIO,
  so execve() of a large process blocked ptrace_attach() and every
  exec_update_lock reader for the duration of the teardown.

  The old mm is now stashed in bprm->old_mm and released from
  setup_new_exec() after both locks are dropped, with a backstop in
  free_bprm() for the error paths"

* tag 'kernel-7.2-rc1.task_exec_state' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
  exec: free the old mm outside the exec locks
  exec_state: relocate dumpable information
  ptrace: add ptracer_access_allowed()
  exec: introduce struct task_exec_state
  sched/coredump: introduce enum task_dumpable
2026-06-15 03:00:58 +05:30
..
2026-02-11 13:44:47 +01:00
2025-10-22 07:54:33 +02:00
2026-04-02 15:52:49 +02:00
2026-03-18 15:11:40 +05:30
2026-03-19 23:55:27 +01:00
2026-01-20 19:44:19 -08:00
2026-04-03 16:53:50 -04:00
2025-11-21 11:21:31 +01:00
2026-04-04 08:10:37 -06:00
2026-03-16 13:16:49 +01:00
2026-03-02 17:08:05 -05:00
2025-09-23 11:13:22 +02:00
2026-03-31 19:15:21 +02:00
2026-05-19 17:26:07 +02:00
2025-10-22 07:55:00 +02:00
2025-11-01 12:44:49 -05:00
2025-12-13 20:04:32 +12:00
2026-03-23 13:33:51 -04:00
2026-04-07 17:38:07 +02:00
2025-12-23 11:23:10 -08:00
2026-02-27 16:40:16 +01:00
2025-10-29 18:28:29 -07:00
2026-01-12 16:52:09 +01:00
2025-11-04 12:36:02 +01:00
2026-02-23 13:43:16 -08:00
2026-02-06 07:29:14 -07:00
2025-10-22 07:53:15 +02:00
2025-09-23 11:13:22 +02:00
2026-04-05 13:53:28 -07:00
2026-01-05 16:43:31 +01:00
2026-01-11 06:09:11 -10:00
2026-04-01 10:19:41 +02:00
2026-04-03 16:53:50 -04:00
2026-04-03 16:53:50 -04:00
2026-03-18 09:59:57 +00:00
2026-04-06 11:39:54 +02:00
2026-04-05 13:53:00 -07:00
2025-11-23 12:30:40 +01:00
2026-03-17 15:34:47 +05:30
2025-12-29 11:53:38 +01:00
2026-01-26 20:02:27 -08:00
2026-03-08 11:06:53 +01:00
2025-09-23 13:28:20 -04:00
2025-11-05 23:58:20 +01:00
2025-11-03 17:41:17 +01:00
2026-03-27 07:35:05 -07:00
2026-01-30 11:34:34 +00:00
2026-04-05 13:53:10 -07:00
2026-02-10 11:39:31 +01:00
2026-02-10 11:39:30 +01:00
2026-01-11 06:09:11 -10:00
2026-04-20 11:35:17 -07:00
2025-10-30 18:35:26 +01:00
2025-10-24 21:39:27 +02:00
2025-10-31 10:16:23 +01:00
2026-03-27 17:14:31 -07:00
2026-05-26 11:02:01 +02:00
2026-02-27 16:40:16 +01:00
2026-01-11 06:09:11 -10:00
2026-03-08 11:06:53 +01:00
2025-11-28 09:21:18 -07:00
2026-03-31 07:04:00 -06:00
2026-05-05 16:12:07 +08:00
2026-03-25 20:11:29 +01:00
2026-03-13 08:22:54 +01:00
2026-03-12 15:05:34 +01:00
2026-04-13 08:39:51 -07:00
2026-04-06 09:06:39 +02:00
2025-11-03 17:41:18 +01:00
2026-03-30 16:43:24 -06:00
2026-01-30 18:26:59 -08:00