Re: [PATCH RESEND 2/2] selftest: seccomp: Adjust test for using both `STRICT` and `FILTER`

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] The updated selftests crash with SIGKILL due to unhandled strict seccomp constraints.

Pre-existing issues:
- [Critical] The internal kernel mode `SECCOMP_MODE_COMBINED` is leaked to userspace via `prctl` and `/proc/pid/status`, causing ABI breakage.
--

commit fb241f2f33856c48dd4d8cab04014fc026770de7
Author: Jamie Hill-Daniel <clubby789@gmail.com>

selftest: seccomp: Adjust test for using both STRICT and FILTER

This patch updates the seccomp selftests to expect a successful transition
to STRICT mode after FILTER mode is already applied, renaming the test
to mode_filter_combined.

> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
[ ... ]
> -TEST(mode_filter_cannot_move_to_strict)
> +TEST(mode_filter_combined)
>  {
>  	struct sock_filter filter[] = {
>  		BPF_STMT(BPF_RET|BPF_K, SECCOMP_RET_ALLOW),
> @@ -534,8 +534,7 @@ TEST(mode_filter_cannot_move_to_strict)
>  	ASSERT_EQ(0, ret);
>  
>  	ret = prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT, NULL, 0, 0);
> -	EXPECT_EQ(-1, ret);
> -	EXPECT_EQ(EINVAL, errno);
> +	ASSERT_EQ(0, ret);

[Severity: Medium]
When this test finishes, the kselftest framework attempts to exit the process
by calling glibc's _exit(), which invokes the exit_group syscall.

Since strict seccomp mode only permits read, write, _exit (__NR_exit),
and sigreturn, won't the forbidden exit_group syscall cause the test process
to be immediately killed with SIGKILL?

It appears the test must manually exit via syscall(__NR_exit, 0) to avoid
falsely reporting a failure, similar to how TEST(mode_strict_support)
handles it.

Additionally, does this patch also need to update
TEST(seccomp_syscall_mode_lock)?

With the new kernel behavior, that test's transition to strict mode will now
succeed, causing it to execute the seccomp() syscall while in strict mode,
which will result in another immediate SIGKILL.

[Severity: Critical]
This is a pre-existing issue, but the underlying kernel patch appears to leak
the internal SECCOMP_MODE_COMBINED (4) state to userspace.

When a process successfully transitions to strict mode after a filter is
installed, its internal state becomes 4.

If this value is directly exposed to userspace via prctl(PR_GET_SECCOMP)
and the /proc/pid/status file's Seccomp: field, could this break ABI
contracts?

The UAPI headers only define SECCOMP_MODE_DISABLED (0), 
SECCOMP_MODE_STRICT (1), and SECCOMP_MODE_FILTER (2). 

Exposing an undocumented internal mode to userspace might cause sandbox
monitoring tools, init systems, or security daemons that expect standard
UAPI values to malfunction or crash.

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526-seccomp-combined-v1-0-304b1cc3ad24@hill-daniel.co.uk?part=2