Seccomp gains non-cooperative pin redirect to close TOCTOU
A kernel series lets sandbox supervisors feed immutable syscall arguments into uncooperative targets without a trusted setup window.
Seccomp user notifications have long carried a documented time-of-check/time-of-use hole that blocks their use as a real security policy. After a supervisor inspects a trapped syscall and allows it to continue, the target (or a thread sharing its address space) can rewrite the memory behind any pointer argument before the kernel reads it.
Cong Wang has posted a Linux kernel series that closes that race without any cooperation from the sandboxed binary. The design targets the common fork-and-exec sandbox model used by wrappers in the Firejail and Bubblewrap style, where there is no trusted post-exec window in which the target could map and seal a shared buffer itself.
The supervisor first has the kernel install a sealed, read-only shared mapping of a supervisor-owned, write-sealed memfd directly into the trapped task's address space. Sealing means the target and any CLONE_VM peer cannot unmap, remap, reprotect, or MAP_FIXED-stomp the region, while the supervisor still stages data through its own pre-seal mapping of the same memfd. The supervisor then resumes the syscall with selected argument registers rewritten to point into that pin. Each pointer substitution is checked so the full access range still lies inside a live sealed pin backed by that memfd; original registers are restored on return to userspace for ABI compliance.
Execve is a first-class case: the pathname is copied from the pin before the old address space is torn down, and register restore is skipped once the program image has been replaced. Redirected calls are re-validated against outer filters in the stack so an inner notifier cannot smuggle a substituted call past a stricter outer policy. The feature is opt-in per listener, limited to one redirect-capable filter in a chain, and so far enabled only on x86_64. Redirects of rt_sigreturn and the clone/fork family are refused.
Underneath, the work generalizes mmap placement so a mapping can be installed into another task's mm while still honoring the file's own placement rules, which is what makes the remote pin install possible.