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

Jens Axboe
2026-02-23T19:15:19Z

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.

--
Jens Axboe