Re: [syzbot] [io-uring?] WARNING in __secure_computing

Kees Cook
2026-02-24T00:08:13Z

On Mon, Feb 23, 2026 at 12:15:17PM -0700, Jens Axboe wrote:
> On 2/20/26 6:44 AM, Jens Axboe wrote:
> > On 2/19/26 11:53 AM, Kees Cook wrote:
> >> On Wed, Feb 18, 2026 at 09:27:07AM -0700, Jens Axboe wrote:
> >>> On 2/17/26 9:00 PM, syzbot wrote:
> >>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13256722580000
> >>>> [...]
> >>>> WARNING: kernel/seccomp.c:1407 at __secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407, CPU#1: syz.0.17/6077
> >>
> >> This is:
> >>
> >> /* Surviving SECCOMP_RET_KILL_* must be proactively impossible. */
> >> case SECCOMP_MODE_DEAD:
> >> WARN_ON_ONCE(1);
> >> do_exit(SIGKILL);
> >> return -1;
> >>
> >> It's nice to see we caught an impossible state! :) Now we just need to
> >> figure out what the repro is doing.
> >>
> >>> Not io_uring, no seccomp label that I can find...
> >>
> >> Why do you say this? The reproducer sets up io_uring and then calls
> >> seccomp:
> >
> > Because I don't see any related interaction there at all. As per usual,
> > the syz repro ends up doing some odd SQ tweaking, which results in a
> > bunch of readv and NOPs being issued. The former against signalfd. I
> > don't see anything odd on the io_uring side outside of that. Well
> > there's the usual nonsensical fuzzing io_uring_enter flag setting, like
> > SQ_* which don't make sense for the ring setup, but these are just
> > ignored.
> >
> > It is possible that because of the tons of readv being queued that some
> > io-wq activity will be occuring, and that could slow down certain paths
> > like the signal handling. But seem orthogonal to me, as you could most
> > likely accomplish the same with userside threads too.
> >
> > I could be wrong of course! Note that I'm gone until next week, so not
> > going to spend any time looking at this before then. Please do dive in
> > if you have time, though...
> >
> >> int main(void)
> >> {
> >> ...
> >> // io_uring_enter arguments: [
> >> // fd: fd_io_uring (resource)
> >> // to_submit: int32 = 0x847ba (4 bytes)
> >> // min_complete: int32 = 0x0 (4 bytes)
> >> // flags: io_uring_enter_flags = 0xe (8 bytes)
> >> // sigmask: nil
> >> // size: len = 0x0 (8 bytes)
> >> // ]
> >> syscall(
> >> __NR_io_uring_enter, /*fd=*/r[1], /*to_submit=*/0x847ba,
> >> /*min_complete=*/0,
> >> /*flags=IORING_ENTER_EXT_ARG|IORING_ENTER_SQ_WAIT|IORING_ENTER_SQ_WAKEUP*/
> >> 0xeul, /*sigmask=*/0ul, /*size=*/0ul);
> >> // seccomp$SECCOMP_SET_MODE_FILTER_LISTENER arguments: [
> >> // op: const = 0x1 (8 bytes)
> >> // flags: seccomp_flags_listener = 0x0 (8 bytes)
> >> // arg: ptr[in, sock_fprog] {
> >> // sock_fprog {
> >> // len: len = 0x1 (2 bytes)
> >> // pad = 0x0 (6 bytes)
> >> // filter: ptr[in, array[sock_filter]] {
> >> // array[sock_filter] {
> >> // sock_filter {
> >> // code: int16 = 0x6 (2 bytes)
> >> // jt: int8 = 0xff (1 bytes)
> >> // jf: int8 = 0x1 (1 bytes)
> >> // k: int32 = 0x3fff0000 (4 bytes)
> >> // }
> >> // }
> >> // }
> >> // }
> >> // }
> >> // ]
> >> // returns fd_seccomp
> >> NONFAILING(*(uint16_t*)0x200000000240 = 1);
> >> NONFAILING(*(uint64_t*)0x200000000248 = 0x2000000003c0);
> >> NONFAILING(*(uint16_t*)0x2000000003c0 = 6);
> >> NONFAILING(*(uint8_t*)0x2000000003c2 = -1);
> >> NONFAILING(*(uint8_t*)0x2000000003c3 = 1);
> >> NONFAILING(*(uint32_t*)0x2000000003c4 = 0x3fff0000);
> >> syscall(__NR_seccomp, /*op=*/1ul, /*flags=*/0ul, /*arg=*/0x200000000240ul);
> >> return 0;
> >> }
> >>
> >> So something has gone weird here, I assume related to seccomp listener
> >> vs io_uring and process death.
> >
> > See above on potentially lots of threads being kicked off. But probably
> > reproducing this first would be a good step towards fixing it.
>
> No threads are being kicked off - from strace, this seems to be the key:
>
> seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=1, filter=0x2000000003c0}) = 0
> exit_group(0) = 231
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
> exit_group(11)
>
> as that WARN_ON_ONCE() in the report is indeed triggered off the
> 2nd exit_group() syscall.

Thank you for tracking this down! I've been busy with fixing my rc1
kmalloc_obj breakages and didn't have time to look at this more.

--
Kees Cook