Re: [PATCH RESEND 1/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] SECCOMP_MODE_COMBINED allows a ptracer to completely bypass strict mode restrictions via system call manipulation.
- [High] The internal SECCOMP_MODE_COMBINED constant is leaked to userspace, violating ABI stability.
- [High] Checkpoint/Restore (CRIU) and Ptrace filter dumping are broken for processes in COMBINED mode.
- [High] Thread synchronization (TSYNC) is broken and causes state inconsistencies for processes in COMBINED mode.
- [Medium] The transition from SECCOMP_MODE_STRICT to SECCOMP_MODE_COMBINED is structurally unreachable.
--

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

seccomp: Allow using SECCOMP_MODE_STRICT with SECCOMP_MODE_FILTER

It is currently impossible to enable SECCOMP_MODE_STRICT if
SECCOMP_MODE_FILTER is enabled, and vice-versa. This makes using
seccomp difficult in environments such as Docker, which installs a
seccomp filter by default.

Introduce a new internal SECCOMP_MODE_COMBINED
that runs strict checks, followed by any installed filters.

Link: https://github.com/moby/moby/issues/42082

> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 25f62867a16d9..8201a050d358f 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -33,6 +33,8 @@
>  
>  /* Not exposed in headers: strictly internal use only. */
>  #define SECCOMP_MODE_DEAD	(SECCOMP_MODE_FILTER + 1)
> +/* Run SECCOMP_MODE_STRICT checks, followed by SECCOMP_MODE_FILTER  */
> +#define SECCOMP_MODE_COMBINED (SECCOMP_MODE_DEAD + 1)

[Severity: High]
Does this new internal mode leak to userspace and break ABI expectations?

Looking at prctl_get_seccomp(), it returns current->seccomp.mode directly.
This will now return 4 to userspace for tasks in combined mode, but userspace
utilities like systemd and container runtimes strictly expect the mode to be
0 (DISABLED), 1 (STRICT), or 2 (FILTER).

[Severity: High]
Will setting current->seccomp.mode to SECCOMP_MODE_COMBINED break thread
synchronization (TSYNC)?

seccomp_can_sync_threads() validates sibling threads and only allows
synchronization if they are in SECCOMP_MODE_DISABLED or
SECCOMP_MODE_FILTER. If any thread is in SECCOMP_MODE_COMBINED, this
validation unconditionally fails and SECCOMP_FILTER_FLAG_TSYNC operations
abort with -ESRCH.

[Severity: High]
Can this new mode prevent checkpoint/restore (CRIU) and ptrace filter
dumping?

get_nth_filter(), which is the backend for PTRACE_SECCOMP_GET_FILTER and
seccomp metadata inspection, explicitly enforces the condition:

    if (task->seccomp.mode != SECCOMP_MODE_FILTER)
        return ERR_PTR(-EINVAL);

When a process runs in SECCOMP_MODE_COMBINED, this validation will fail,
making it impossible to inspect, dump, or checkpoint the attached seccomp
BPF filters.

[ ... ]

> @@ -432,14 +434,21 @@ static u32 seccomp_run_filters(const struct seccomp_data *sd,
>  }
>  #endif /* CONFIG_SECCOMP_FILTER */
>  
> -static inline bool seccomp_may_assign_mode(unsigned long seccomp_mode)
> +/**
> + * seccomp_needs_combined: internal function for checking if requested mode
> + * needs to be upgraded to SECCOMP_MODE_COMBINED.
> + *
> + */
> +static inline bool seccomp_needs_combined(unsigned long seccomp_mode)
>  {
>  	assert_spin_locked(&current->sighand->siglock);
>  
> -	if (current->seccomp.mode && current->seccomp.mode != seccomp_mode)
> -		return false;
> +	if ((current->seccomp.mode == SECCOMP_MODE_STRICT ||
> +	     current->seccomp.mode == SECCOMP_MODE_FILTER) &&
> +	    current->seccomp.mode != seccomp_mode)
> +		return true;

[Severity: Medium]
Is the transition from SECCOMP_MODE_STRICT to SECCOMP_MODE_COMBINED
structurally unreachable?

In strict mode, the __secure_computing_strict() hook runs during syscall
entry and unconditionally kills the process via SIGKILL if it attempts to
execute any syscall other than read, write, _exit, or sigreturn.

Any attempt to invoke prctl or seccomp to install a filter while in
strict mode will result in immediate termination, preventing the upgrade.

> -	return true;
> +	return false;
>  }

[ ... ]

> @@ -1407,6 +1416,9 @@ int __secure_computing(void)
>  		WARN_ON_ONCE(1);
>  		do_exit(SIGKILL);
>  		return -1;
> +	case SECCOMP_MODE_COMBINED:
> +		__secure_computing_strict(this_syscall);
> +		return __seccomp_filter(this_syscall, false);

[Severity: High]
Could this sequence allow a ptracer to completely bypass strict mode
restrictions via system call manipulation?

If the original system call is permitted by the strict check (for example,
read), __secure_computing_strict() passes and __seccomp_filter()
evaluates the BPF filter.

If the filter returns SECCOMP_RET_TRACE, a ptracer is notified and can use
PTRACE_SETREGS to modify the system call number (for example, changing it
to execve).

While __seccomp_filter() correctly re-evaluates the newly injected syscall
against the BPF filter, __secure_computing_strict() is never re-run. If
the filter permits the new syscall, it will execute, allowing the ptracer to
completely bypass the strict mode sandbox.

>  	default:
>  		BUG();
>  	}

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