Re: [PATCH v4 0/6] seccomp: non-cooperative pinned-memfd argument redirect

[Cong Wang]

On Fri, Jun 26, 2026 at 9:43 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, 26 Jun 2026 18:22:13 -0700 Cong Wang <xiyou.wangcong@xxxxxxxxx> wrote:
>
> > The seccomp user-notification SECCOMP_USER_NOTIF_FLAG_CONTINUE response
> > carries an inherent TOCTOU: once the supervisor decides to let a syscall
> > continue, the target (or a CLONE_VM peer) can rewrite the memory behind a
> > pointer argument before the kernel reads it. This is documented in the
> > UAPI header and is why the notifier "cannot be used to implement a
> > security policy" today.
> >
> > The cooperative way around this is for the target to map a shared memfd
> > and mseal() it during a trusted setup window, so the supervisor can hand
> > the kernel an immutable buffer. That window does not exist for the common
> > fork()+execve() sandbox model, where the supervisor wants to confine an
> > uncooperative (or legacy) binary it did not write.
> >
> > This series lets the supervisor close the TOCTOU without any target-side
> > cooperation:
>
> AI review went crazy over this.  I hope there's something useful in there:
>         https://sashiko.dev/#/patchset/20260627012219.1079851-1-xiyou.wangcong@xxxxxxxxx

Thanks for the pointer. I didn't get a notification.

I am addressing these reviews now, and will incorporate them in the next update.

Regards,
Cong