Re: [RFC PATCH 12/24] fork: let kernel callers create embryonic tasks

Hi Andy,

 ---- On Thu, 16 Jul 2026 23:57:58 +0800  Andy Lutomirski <[email protected]> wrote --- 
 > On Thu, Jul 16, 2026 at 8:52 AM Li Chen <[email protected]> wrote:
 > >
 > > A kernel-created task can become visible before it has installed a new
 > > executable image or a valid userspace register frame. Exposing such a task
 > > through ptrace can disclose kernel setup state.
 > >
 > > Add a task-local embryonic flag and an internal clone argument for callers
 > > that need this lifecycle. Reject ptrace access until the creator clears the
 > > flag. Clear it with release ordering and observe it with acquire ordering.
 > > This orders visibility of the completed exec state with the transition.
 > >
 > > Existing fork, vfork, clone, and kernel-thread callers leave the argument
 > > unset and retain their current behavior.
 > >
 > 
 > > --- a/kernel/ptrace.c
 > > +++ b/kernel/ptrace.c
 > > @@ -56,6 +56,8 @@ bool ptracer_access_allowed(struct task_struct *tsk)
 > >         guard(rcu)();
 > >         if (ptrace_parent(tsk) != current)
 > >                 return false;
 > > +       if (task_is_embryonic_exec(tsk))
 > > +               return false;
 > >         es = task_exec_state_rcu(tsk);
 > >         return READ_ONCE(es->dumpable) == TASK_DUMPABLE_OWNER ||
 > >                ptracer_capable(tsk, es->user_ns);
 > > @@ -312,6 +314,8 @@ static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
 > >                 WARN(1, "denying ptrace access check without PTRACE_MODE_*CREDS\n");
 > >                 return -EPERM;
 > >         }
 > > +       if (task_is_embryonic_exec(task))
 > > +               return -EPERM;
 > 
 > Would it be better to use a different error code?  -ECONNREFUSED?
 > After all, this isn't a permission failure per se.

Good point. I'm not sure ECONNREFUSED fits outside connection setup,
though. ESRCH may make more sense if the task is meant to appear hidden.
I'll think about this some more.
  
 > There's a not-locally-obvious gotcha here: reading other process
 > attributes prior to calling task_is_embryonic_exec may result in
 > (security-relevant!) data races.  This should at least be documented
 > -- it's critical to check task_is_embryonic_exec *before* trying to
 > read credentials.  Also, I think /proc and many pidfd APIs have the
 > same issue.

Agreed. Patch 15 later in the series already applies this ordering to procfs,
including cached dentry revalidation, and to PIDFD_GET_INFO.

The ordering requirement still needs to be made more explicit. I'll
document it, move the check ahead of ptrace_parent() in
ptracer_access_allowed(), and audit the remaining pidfd users before the
next version.

Regards,
Li​