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

[Andrew Morton]

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