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

[Jens Axboe]

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