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

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 2961f841b025 Merge tag 'turbostat-2026.02.14' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1721315a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=e2f061f80b102378
dashboard link: https://syzkaller.appspot.com/bug?extid=0a4c46806941297fecb9
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=142edb3a580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13256722580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-2961f841.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4f9939f81465/vmlinux-2961f841.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3f9babe832cd/bzImage-2961f841.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+0a4c46...@syzkaller.appspotmail.com

------------[ cut here ]------------
1
WARNING: kernel/seccomp.c:1407 at __secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407, CPU#1: syz.0.17/6077
Modules linked in:
CPU: 1 UID: 0 PID: 6077 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407
Code: 00 e8 96 52 fe ff e8 31 27 ff ff e8 fc 68 6b 00 bf 09 00 00 00 e8 82 f0 be ff e8 3d 79 6b 00 e9 06 fe ff ff e8 13 27 ff ff 90 <0f> 0b 90 e8 da 68 6b 00 bf 09 00 00 00 e8 60 f0 be ff e8 fb 26 ff
RSP: 0018:ffffc9000413fed0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffc9000413ff48 RCX: ffffffff82097151
RDX: ffff888035c04900 RSI: ffffffff8209730d RDI: ffff888035c04900
RBP: 0000000000000003 R08: 0000000000000005 R09: 0000000000000003
R10: 0000000000000003 R11: 0000000000000000 R12: 00000000000001b4
R13: 00000000000001b4 R14: ffff888035c04900 R15: 0000000000000001
FS: 0000555575c2e500(0000) GS:ffff8880d644a000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f20e8a71fc0 CR3: 00000000373f5000 CR4: 0000000000352ef0
Call Trace:
<TASK>
syscall_trace_enter include/linux/entry-common.h:112 [inline]
syscall_enter_from_user_mode_work include/linux/entry-common.h:156 [inline]
syscall_enter_from_user_mode include/linux/entry-common.h:187 [inline]
do_syscall_64+0x568/0xf80 arch/x86/entry/syscall_64.c:90
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f20e8b9c629
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd25984108 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
RAX: ffffffffffffffda RBX: 00007ffd259841f0 RCX: 00007f20e8b9c629
RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
RBP: 000000000000f6e1 R08: 0000000000000001 R09: 0000000000000000
R10: 0000001b2d120000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f20e8e15fac R14: 00007f20e8e15fa8 R15: 00007f20e8e15fa0
</TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Jens Axboe]

Not io_uring, no seccomp label that I can find...

#syz set subsystems: kernel

--
Jens Axboe

[Kees Cook]

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:

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.

-Kees

--
Kees Cook

[Jens Axboe]

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...

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

[Jens Axboe]

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

[Kees Cook]

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

[Oleg Nesterov]

On 02/17, syzbot wrote:
>
> WARNING: kernel/seccomp.c:1407 at __secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407, CPU#1: syz.0.17/6077

#syz test

So signalfd_dequeue() is called by get_signal() -> task_work_run(), the work
was queued by io_uring... Thanks Kusaram.

Obviously this is not the right fix (and we should not blame io_uring), but
lets test to ensure.

Oleg.
---

diff --git a/fs/signalfd.c b/fs/signalfd.c
index dff53745e352..8819dea943f8 100644
--- a/fs/signalfd.c
+++ b/fs/signalfd.c
@@ -158,6 +158,9 @@ static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, kernel_siginfo_t *info
ssize_t ret;
DECLARE_WAITQUEUE(wait, current);

+ if (current->seccomp.mode == SECCOMP_MODE_FILTER + 1) // SECCOMP_MODE_DEAD
+ return -EINTR;
+
spin_lock_irq(&current->sighand->siglock);
ret = dequeue_signal(&ctx->sigmask, info, &type);
switch (ret) {

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+0a4c46...@syzkaller.appspotmail.com
Tested-by: syzbot+0a4c46...@syzkaller.appspotmail.com

Tested on:

commit: 7ca6d1cf Merge tag 'powerpc-7.0-4' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=106df3d6580000
kernel config: https://syzkaller.appspot.com/x/.config?x=4f34697150c7a709

dashboard link: https://syzkaller.appspot.com/bug?extid=0a4c46806941297fecb9
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44

patch: https://syzkaller.appspot.com/x/patch.diff?x=12f9946a580000

Note: testing is done by a robot and is best-effort only.