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

[Jens Axboe <axboe@kernel.dk>]

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.

-- 
Jens Axboe