Re: [PATCH v4] seccomp: restore knotif->state when SECCOMP_ADDFD_FLAG_SEND is interrupted

[Kees Cook]

On Sun, Sep 20, 2026 at 06:59:10PM +0000, Hui Peng wrote:
> Fix this by restoring knotif->state back to SECCOMP_NOTIFY_SENT if
> SECCOMP_ADDFD_FLAG_SEND was set and kaddfd was not consumed before the
> interrupted wait. Also add a seccomp_bpf selftest
> (user_notification_addfd_send_interrupted) covering this race.

Yeah, this fix is the same restoration logic as seccomp_notify_recv()
uses (although that may actually need "if (state == SECCOMP_NOTIFY_SENT) ..."
added). It does make it clear there is a missing state in the state
machine. SECCOMP_NOTIFY_REPLIES means both "A reply is reserved" and
"A reply has been delivered". But the hidden state is maintained:
"REPLIED + queued ADDFD+SEND" == in flight, and "REPLIED + no queued
addfd" == delivered.

Thank you for the selftest addition, the sched trick is nice!

> Tested in QEMU against Linux 7.3.0-rc3 by exercising kernel/seccomp.c
> and verifying the fix with KASAN enabled.

I've verified this now too. It's kind of a ugly problem because unlucky
timing makes it look like the returned fd is fd 0. :(

> [...]
> +	/*
> +	 * Demote the tracee to SCHED_IDLE and promote the supervisor to
> +	 * SCHED_FIFO(99) on the same CPU.
> +	 */
> +	sched_setscheduler(pid, SCHED_IDLE, &sp_tracee_idle);

Unchecked return value?

> +	if (sched_setscheduler(0, SCHED_FIFO, &sp_supervisor_fifo) != 0) {
> +		close(listener);
> +		close(memfd);
> +		kill(pid, SIGKILL);
> +		waitpid(pid, NULL, 0);
> +		SKIP(return, "SCHED_FIFO requires CAP_SYS_NICE");
> +	}

Instead of this you may want to look at FIXTURE_TEARDOWN to clean up
(though it's not strictly needed since the harness is run in a
subprocess so all these go away on test exit). The one thing that might
be worth doing is making sure sched_setscheduler(0, SCHED_OTHER, ...)
happens ASAP or the test could block everything on a single CPU
machine/VM/CI.

> [...]
> +	sig_pid = fork();
> +	ASSERT_GE(sig_pid, 0);
> +	if (sig_pid == 0) {
> +		sched_setscheduler(0, SCHED_FIFO, &sp_sig_helper_fifo);

Missed return value check here too.

> +		kill(parent_pid, SIGUSR1);
> +		_exit(0);
> +	}
> +
> +	EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_ADDFD, &addfd), -1);
> +	EXPECT_EQ(errno, EINTR);
> +	EXPECT_EQ(waitpid(sig_pid, &status, 0), sig_pid);
> +
> +	/*
> +	 * Restore normal scheduling and sleep briefly so the woken tracee
> +	 * runs in do_user_notif(). With knotif->state restored to
> +	 * SECCOMP_NOTIFY_SENT, the tracee must loop back to sleep waiting for
> +	 * the notification reply rather than returning 0 from __NR_getppid.
> +	 */
> +	sched_setscheduler(0, SCHED_OTHER, &sp_tracee_idle);
> +	sched_setscheduler(pid, SCHED_OTHER, &sp_tracee_idle);

Need to check these too...

> +	nanosleep(&delay, NULL);
> +
> +	/*
> +	 * Retry SECCOMP_IOCTL_NOTIF_ADDFD. Because knotif->state is
> +	 * SECCOMP_NOTIFY_SENT, the retry succeeds (returns 42) instead of
> +	 * failing with -EINPROGRESS, installs FD 42 into the tracee, and wakes
> +	 * the tracee to complete the syscall with return value 42.
> +	 */
> +	EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_ADDFD, &addfd), 42);
> +
> +	EXPECT_EQ(waitpid(pid, &status, 0), pid);
> +	EXPECT_EQ(true, WIFEXITED(status));
> +	EXPECT_EQ(0, WEXITSTATUS(status));
> +
> +	close(listener);
> +	close(memfd);
> +}
> +
>  #ifndef SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP
>  #define SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP (1UL << 0)
>  #define SECCOMP_IOCTL_NOTIF_SET_FLAGS  SECCOMP_IOW(4, __u64)
> -- 
> 2.49.0

Thank you for the test, it really helps see the shape of the issue.

-Kees

-- 
Kees Cook