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

[Kees Cook <kees@kernel.org>]

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