From: sashiko-bot@kernel.org
To: "Jamie Hill-Daniel" <clubby789@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v2 1/3] seccomp: Store death as a separate field
Date: Mon, 15 Jun 2026 16:34:13 +0000 [thread overview]
Message-ID: <20260615163413.648FA1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260615-seccomp-combined-v2-1-41687a943ae0@hill-daniel.co.uk>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The newly added defense `if (unlikely(current->seccomp.dead))` was omitted from the non-BPF fallback implementation of `secure_computing_strict()`.
--
commit 17b53379696e6ea38281041129401658643c996d
Author: Jamie Hill-Daniel <clubby789@gmail.com>
seccomp: Store death as a separate field
This patch removes SECCOMP_MODE_DEAD and stores the death state in a new
bitfield within struct seccomp. This allows the mode field to strictly store
the current seccomp mode while exposing it to userspace.
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 066909393c38f..2d21cb6bbd94d 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
[ ... ]
> @@ -1396,17 +1393,19 @@ int __secure_computing(void)
>
> this_syscall = syscall_get_nr(current, current_pt_regs());
>
> + /* Surviving SECCOMP_RET_KILL_* must be proactively impossible. */
> + if (unlikely(current->seccomp.dead)) {
> + WARN_ON_ONCE(1);
> + do_exit(SIGKILL);
> + return -1;
> + }
> +
[Severity: High]
Is it possible we need this same check in the non-BPF fallback version of
secure_computing_strict()?
When CONFIG_HAVE_ARCH_SECCOMP_FILTER is disabled, secure_computing_strict()
evaluates current->seccomp.mode. Previously, if a killed process miraculously
survived do_exit() and issued another syscall, the mode would be
SECCOMP_MODE_DEAD and trigger a BUG() instead of executing
__secure_computing_strict():
kernel/seccomp.c:secure_computing_strict() {
...
if (mode == SECCOMP_MODE_DISABLED)
return;
else if (mode == SECCOMP_MODE_STRICT)
__secure_computing_strict(this_syscall);
else
BUG();
}
With the new dead bitfield, if the process survives and issues a valid
strict-mode syscall (e.g. exit), the mode remains SECCOMP_MODE_STRICT.
It appears we'll simply execute __secure_computing_strict() again and
return successfully without killing the process, neutralizing the fail-safe.
> switch (mode) {
> case SECCOMP_MODE_STRICT:
> __secure_computing_strict(this_syscall); /* may call do_exit */
> return 0;
> case SECCOMP_MODE_FILTER:
> return __seccomp_filter(this_syscall, false);
> - /* Surviving SECCOMP_RET_KILL_* must be proactively impossible. */
> - case SECCOMP_MODE_DEAD:
> - WARN_ON_ONCE(1);
> - do_exit(SIGKILL);
> - return -1;
> default:
> BUG();
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-seccomp-combined-v2-0-41687a943ae0@hill-daniel.co.uk?part=1
next prev parent reply other threads:[~2026-06-15 16:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 16:20 [PATCH v2 0/3] seccomp: Allow using SECCOMP_MODE_STRICT with SECCOMP_MODE_FILTER Jamie Hill-Daniel
2026-06-15 16:20 ` [PATCH v2 1/3] seccomp: Store death as a separate field Jamie Hill-Daniel
2026-06-15 16:34 ` sashiko-bot [this message]
2026-06-15 16:20 ` [PATCH v2 2/3] seccomp: Allow upgrading to strict mode after enabling filters Jamie Hill-Daniel
2026-06-15 16:35 ` sashiko-bot
2026-06-15 16:20 ` [PATCH v2 3/3] selftest: seccomp: Adjust tests for using both STRICT and FILTER Jamie Hill-Daniel
2026-06-15 16:32 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260615163413.648FA1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clubby789@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox