[syzbot] [io-uring?] INFO: task hung in io_uring_del_tctx_node (5)
1 view
Skip to first unread message
syzbot
Oct 27, 2025, 5:07:38 PM (2 days ago) Oct 27
to ax...@kernel.dk, io-u...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,
syzbot found the following issue on:
HEAD commit: 72fb0170ef1f Add linux-next specific files for 20251024
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13087be2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=e812d103f45aa955
dashboard link: https://syzkaller.appspot.com/bug?extid=10a9b495f54a17b607a6
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14725d2f980000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11233b04580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/be1fa3d1f761/disk-72fb0170.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/57302bf7af40/vmlinux-72fb0170.xz
kernel image: https://storage.googleapis.com/syzbot-assets/91c806bb2a2b/bzImage-72fb0170.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+10a9b4...@syzkaller.appspotmail.com
INFO: task syz.0.17:6027 blocked for more than 143 seconds.
Not tainted syzkaller #0
Blocked by coredump.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.0.17 state:D stack:25752 pid:6027 tgid:6026 ppid:5955 task_flags:0x400548 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5254 [inline]
__schedule+0x17c4/0x4d60 kernel/sched/core.c:6862
__schedule_loop kernel/sched/core.c:6944 [inline]
schedule+0x165/0x360 kernel/sched/core.c:6959
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016
__mutex_lock_common kernel/locking/mutex.c:676 [inline]
__mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760
io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
io_uring_clean_tctx+0xd4/0x1a0 io_uring/tctx.c:195
io_uring_cancel_generic+0x6ca/0x7d0 io_uring/io_uring.c:3363
io_uring_files_cancel include/linux/io_uring.h:19 [inline]
do_exit+0x345/0x2300 kernel/exit.c:912
do_group_exit+0x21c/0x2d0 kernel/exit.c:1107
get_signal+0x1285/0x1340 kernel/signal.c:3034
arch_do_signal_or_restart+0xa0/0x790 arch/x86/kernel/signal.c:337
exit_to_user_mode_loop+0x72/0x130 kernel/entry/common.c:40
exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
do_syscall_64+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f887d98efc9
RSP: 002b:00007f887e743038 EFLAGS: 00000246 ORIG_RAX: 000000000000010e
RAX: fffffffffffffdfe RBX: 00007f887dbe5fa0 RCX: 00007f887d98efc9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00007f887da11f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f887dbe6038 R14: 00007f887dbe5fa0 R15: 00007ffda9831b38
</TASK>
INFO: task syz.1.18:6058 blocked for more than 145 seconds.
Not tainted syzkaller #0
Blocked by coredump.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.1.18 state:D stack:28104 pid:6058 tgid:6057 ppid:6038 task_flags:0x400548 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5254 [inline]
__schedule+0x17c4/0x4d60 kernel/sched/core.c:6862
__schedule_loop kernel/sched/core.c:6944 [inline]
schedule+0x165/0x360 kernel/sched/core.c:6959
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016
__mutex_lock_common kernel/locking/mutex.c:676 [inline]
__mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760
io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
io_uring_clean_tctx+0xd4/0x1a0 io_uring/tctx.c:195
io_uring_cancel_generic+0x6ca/0x7d0 io_uring/io_uring.c:3363
io_uring_files_cancel include/linux/io_uring.h:19 [inline]
do_exit+0x345/0x2300 kernel/exit.c:912
do_group_exit+0x21c/0x2d0 kernel/exit.c:1107
get_signal+0x1285/0x1340 kernel/signal.c:3034
arch_do_signal_or_restart+0xa0/0x790 arch/x86/kernel/signal.c:337
exit_to_user_mode_loop+0x72/0x130 kernel/entry/common.c:40
exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
do_syscall_64+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f37d438efc9
RSP: 002b:00007f37d5232038 EFLAGS: 00000246 ORIG_RAX: 000000000000010e
RAX: fffffffffffffdfe RBX: 00007f37d45e5fa0 RCX: 00007f37d438efc9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00007f37d4411f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f37d45e6038 R14: 00007f37d45e5fa0 R15: 00007ffc85237d08
</TASK>
Showing all locks held in the system:
1 lock held by khungtaskd/31:
#0: ffffffff8e13d5a0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
#0: ffffffff8e13d5a0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:867 [inline]
#0: ffffffff8e13d5a0 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x2e/0x180 kernel/locking/lockdep.c:6775
3 locks held by kworker/u8:3/37:
#0: ffff88813fe69948 ((wq_completion)events_unbound#2){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3238 [inline]
#0: ffff88813fe69948 ((wq_completion)events_unbound#2){+.+.}-{0:0}, at: process_scheduled_works+0x9b4/0x17b0 kernel/workqueue.c:3346
#1: ffffc90000ad7ba0 ((linkwatch_work).work){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3239 [inline]
#1: ffffc90000ad7ba0 ((linkwatch_work).work){+.+.}-{0:0}, at: process_scheduled_works+0x9ef/0x17b0 kernel/workqueue.c:3346
#2: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: linkwatch_event+0xe/0x60 net/core/link_watch.c:303
3 locks held by kworker/u8:7/3579:
#0: ffff88802f51d148 ((wq_completion)ipv6_addrconf){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3238 [inline]
#0: ffff88802f51d148 ((wq_completion)ipv6_addrconf){+.+.}-{0:0}, at: process_scheduled_works+0x9b4/0x17b0 kernel/workqueue.c:3346
#1: ffffc9000c717ba0 ((work_completion)(&(&ifa->dad_work)->work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3239 [inline]
#1: ffffc9000c717ba0 ((work_completion)(&(&ifa->dad_work)->work)){+.+.}-{0:0}, at: process_scheduled_works+0x9ef/0x17b0 kernel/workqueue.c:3346
#2: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_net_lock include/linux/rtnetlink.h:130 [inline]
#2: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: addrconf_dad_work+0x112/0x14b0 net/ipv6/addrconf.c:4194
2 locks held by getty/5585:
#0: ffff8880344d50a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
#1: ffffc900036bb2f0 (&ldata->atomic_read_lock){+.+.}-{4:4}, at: n_tty_read+0x43e/0x1400 drivers/tty/n_tty.c:2222
1 lock held by syz.0.17/6027:
#0: ffff888031ece0a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.0.17/6030:
1 lock held by syz.1.18/6058:
#0: ffff88802faa20a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.1.18/6059:
1 lock held by syz.2.19/6082:
#0: ffff88802840c0a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.2.19/6083:
1 lock held by syz.3.20/6106:
#0: ffff8880338140a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.3.20/6107:
1 lock held by syz.4.21/6142:
#0: ffff8880611da0a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.4.21/6143:
1 lock held by syz.5.22/6172:
#0: ffff88801f7c00a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.5.22/6173:
1 lock held by syz.6.23/6204:
#0: ffff88805b6440a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.6.23/6205:
1 lock held by syz.7.24/6242:
#0: ffff8880301c60a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.7.24/6243:
3 locks held by syz-executor/6246:
#0: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]
#0: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock net/core/rtnetlink.c:341 [inline]
#0: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x8e9/0x1c80 net/core/rtnetlink.c:4064
#1: ffff88807b9c1528 (&wg->device_update_lock){+.+.}-{4:4}, at: wg_open+0x227/0x420 drivers/net/wireguard/device.c:50
#2: ffffffff8e143038 (rcu_state.exp_mutex){+.+.}-{4:4}, at: exp_funnel_lock kernel/rcu/tree_exp.h:311 [inline]
#2: ffffffff8e143038 (rcu_state.exp_mutex){+.+.}-{4:4}, at: synchronize_rcu_expedited+0x2f6/0x730 kernel/rcu/tree_exp.h:957
=============================================
NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 31 Comm: khungtaskd Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
nmi_cpu_backtrace+0x39e/0x3d0 lib/nmi_backtrace.c:113
nmi_trigger_cpumask_backtrace+0x17a/0x300 lib/nmi_backtrace.c:62
trigger_all_cpu_backtrace include/linux/nmi.h:160 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:337 [inline]
watchdog+0xfa9/0xff0 kernel/hung_task.c:500
kthread+0x711/0x8a0 kernel/kthread.c:463
ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 UID: 0 PID: 6107 Comm: syz.3.20 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
RIP: 0010:kasan_check_range+0x1d4/0x2c0 mm/kasan/generic.c:200
Code: 01 f3 49 8d 5c 24 07 4d 85 e4 49 0f 49 dc 48 83 e3 f8 49 29 dc 74 12 41 80 3b 00 0f 85 b8 00 00 00 49 ff c3 49 ff cc 75 ee 5b <41> 5c 41 5d 41 5e 41 5f 5d e9 4e d8 2e 09 cc 45 84 ff 75 63 41 f7
RSP: 0018:ffffc9000383f7b0 EFLAGS: 00000256
RAX: ffffffff82431501 RBX: 0000000000000018 RCX: ffffffff824315fd
RDX: 0000000000000001 RSI: 0000000000000018 RDI: ffffc9000383f880
RBP: 0000000000000000 R08: ffffc9000383f897 R09: 1ffff92000707f12
R10: dffffc0000000000 R11: fffff52000707f13 R12: 0000000000000003
R13: ffff888079527128 R14: fffff52000707f13 R15: 1ffff92000707f10
FS: 00007f4e567906c0(0000) GS:ffff888125cdc000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055db9a726918 CR3: 000000002ec48000 CR4: 00000000003526f0
Call Trace:
<TASK>
__asan_memset+0x22/0x50 mm/kasan/shadow.c:84
seq_printf+0xad/0x270 fs/seq_file.c:403
__io_uring_show_fdinfo io_uring/fdinfo.c:142 [inline]
io_uring_show_fdinfo+0x734/0x17d0 io_uring/fdinfo.c:256
seq_show+0x5bc/0x730 fs/proc/fd.c:68
seq_read_iter+0x4ef/0xe20 fs/seq_file.c:230
seq_read+0x369/0x480 fs/seq_file.c:162
vfs_read+0x200/0xa30 fs/read_write.c:570
ksys_read+0x145/0x250 fs/read_write.c:715
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4e5598efc9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4e56790038 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 00007f4e55be6090 RCX: 00007f4e5598efc9
RDX: 0000000000002020 RSI: 00002000000040c0 RDI: 0000000000000004
RBP: 00007f4e55a11f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f4e55be6128 R14: 00007f4e55be6090 R15: 00007ffd5d16a678
</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
syzbot found the following issue on:
HEAD commit: 72fb0170ef1f Add linux-next specific files for 20251024
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13087be2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=e812d103f45aa955
dashboard link: https://syzkaller.appspot.com/bug?extid=10a9b495f54a17b607a6
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14725d2f980000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11233b04580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/be1fa3d1f761/disk-72fb0170.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/57302bf7af40/vmlinux-72fb0170.xz
kernel image: https://storage.googleapis.com/syzbot-assets/91c806bb2a2b/bzImage-72fb0170.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+10a9b4...@syzkaller.appspotmail.com
INFO: task syz.0.17:6027 blocked for more than 143 seconds.
Not tainted syzkaller #0
Blocked by coredump.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.0.17 state:D stack:25752 pid:6027 tgid:6026 ppid:5955 task_flags:0x400548 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5254 [inline]
__schedule+0x17c4/0x4d60 kernel/sched/core.c:6862
__schedule_loop kernel/sched/core.c:6944 [inline]
schedule+0x165/0x360 kernel/sched/core.c:6959
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016
__mutex_lock_common kernel/locking/mutex.c:676 [inline]
__mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760
io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
io_uring_clean_tctx+0xd4/0x1a0 io_uring/tctx.c:195
io_uring_cancel_generic+0x6ca/0x7d0 io_uring/io_uring.c:3363
io_uring_files_cancel include/linux/io_uring.h:19 [inline]
do_exit+0x345/0x2300 kernel/exit.c:912
do_group_exit+0x21c/0x2d0 kernel/exit.c:1107
get_signal+0x1285/0x1340 kernel/signal.c:3034
arch_do_signal_or_restart+0xa0/0x790 arch/x86/kernel/signal.c:337
exit_to_user_mode_loop+0x72/0x130 kernel/entry/common.c:40
exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
do_syscall_64+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f887d98efc9
RSP: 002b:00007f887e743038 EFLAGS: 00000246 ORIG_RAX: 000000000000010e
RAX: fffffffffffffdfe RBX: 00007f887dbe5fa0 RCX: 00007f887d98efc9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00007f887da11f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f887dbe6038 R14: 00007f887dbe5fa0 R15: 00007ffda9831b38
</TASK>
INFO: task syz.1.18:6058 blocked for more than 145 seconds.
Not tainted syzkaller #0
Blocked by coredump.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.1.18 state:D stack:28104 pid:6058 tgid:6057 ppid:6038 task_flags:0x400548 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5254 [inline]
__schedule+0x17c4/0x4d60 kernel/sched/core.c:6862
__schedule_loop kernel/sched/core.c:6944 [inline]
schedule+0x165/0x360 kernel/sched/core.c:6959
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016
__mutex_lock_common kernel/locking/mutex.c:676 [inline]
__mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760
io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
io_uring_clean_tctx+0xd4/0x1a0 io_uring/tctx.c:195
io_uring_cancel_generic+0x6ca/0x7d0 io_uring/io_uring.c:3363
io_uring_files_cancel include/linux/io_uring.h:19 [inline]
do_exit+0x345/0x2300 kernel/exit.c:912
do_group_exit+0x21c/0x2d0 kernel/exit.c:1107
get_signal+0x1285/0x1340 kernel/signal.c:3034
arch_do_signal_or_restart+0xa0/0x790 arch/x86/kernel/signal.c:337
exit_to_user_mode_loop+0x72/0x130 kernel/entry/common.c:40
exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
do_syscall_64+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f37d438efc9
RSP: 002b:00007f37d5232038 EFLAGS: 00000246 ORIG_RAX: 000000000000010e
RAX: fffffffffffffdfe RBX: 00007f37d45e5fa0 RCX: 00007f37d438efc9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00007f37d4411f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f37d45e6038 R14: 00007f37d45e5fa0 R15: 00007ffc85237d08
</TASK>
Showing all locks held in the system:
1 lock held by khungtaskd/31:
#0: ffffffff8e13d5a0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
#0: ffffffff8e13d5a0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:867 [inline]
#0: ffffffff8e13d5a0 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x2e/0x180 kernel/locking/lockdep.c:6775
3 locks held by kworker/u8:3/37:
#0: ffff88813fe69948 ((wq_completion)events_unbound#2){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3238 [inline]
#0: ffff88813fe69948 ((wq_completion)events_unbound#2){+.+.}-{0:0}, at: process_scheduled_works+0x9b4/0x17b0 kernel/workqueue.c:3346
#1: ffffc90000ad7ba0 ((linkwatch_work).work){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3239 [inline]
#1: ffffc90000ad7ba0 ((linkwatch_work).work){+.+.}-{0:0}, at: process_scheduled_works+0x9ef/0x17b0 kernel/workqueue.c:3346
#2: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: linkwatch_event+0xe/0x60 net/core/link_watch.c:303
3 locks held by kworker/u8:7/3579:
#0: ffff88802f51d148 ((wq_completion)ipv6_addrconf){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3238 [inline]
#0: ffff88802f51d148 ((wq_completion)ipv6_addrconf){+.+.}-{0:0}, at: process_scheduled_works+0x9b4/0x17b0 kernel/workqueue.c:3346
#1: ffffc9000c717ba0 ((work_completion)(&(&ifa->dad_work)->work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3239 [inline]
#1: ffffc9000c717ba0 ((work_completion)(&(&ifa->dad_work)->work)){+.+.}-{0:0}, at: process_scheduled_works+0x9ef/0x17b0 kernel/workqueue.c:3346
#2: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_net_lock include/linux/rtnetlink.h:130 [inline]
#2: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: addrconf_dad_work+0x112/0x14b0 net/ipv6/addrconf.c:4194
2 locks held by getty/5585:
#0: ffff8880344d50a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
#1: ffffc900036bb2f0 (&ldata->atomic_read_lock){+.+.}-{4:4}, at: n_tty_read+0x43e/0x1400 drivers/tty/n_tty.c:2222
1 lock held by syz.0.17/6027:
#0: ffff888031ece0a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.0.17/6030:
1 lock held by syz.1.18/6058:
#0: ffff88802faa20a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.1.18/6059:
1 lock held by syz.2.19/6082:
#0: ffff88802840c0a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.2.19/6083:
1 lock held by syz.3.20/6106:
#0: ffff8880338140a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.3.20/6107:
1 lock held by syz.4.21/6142:
#0: ffff8880611da0a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.4.21/6143:
1 lock held by syz.5.22/6172:
#0: ffff88801f7c00a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.5.22/6173:
1 lock held by syz.6.23/6204:
#0: ffff88805b6440a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.6.23/6205:
1 lock held by syz.7.24/6242:
#0: ffff8880301c60a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
3 locks held by syz.7.24/6243:
3 locks held by syz-executor/6246:
#0: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]
#0: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock net/core/rtnetlink.c:341 [inline]
#0: ffffffff8f4edb48 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x8e9/0x1c80 net/core/rtnetlink.c:4064
#1: ffff88807b9c1528 (&wg->device_update_lock){+.+.}-{4:4}, at: wg_open+0x227/0x420 drivers/net/wireguard/device.c:50
#2: ffffffff8e143038 (rcu_state.exp_mutex){+.+.}-{4:4}, at: exp_funnel_lock kernel/rcu/tree_exp.h:311 [inline]
#2: ffffffff8e143038 (rcu_state.exp_mutex){+.+.}-{4:4}, at: synchronize_rcu_expedited+0x2f6/0x730 kernel/rcu/tree_exp.h:957
=============================================
NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 31 Comm: khungtaskd Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
nmi_cpu_backtrace+0x39e/0x3d0 lib/nmi_backtrace.c:113
nmi_trigger_cpumask_backtrace+0x17a/0x300 lib/nmi_backtrace.c:62
trigger_all_cpu_backtrace include/linux/nmi.h:160 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:337 [inline]
watchdog+0xfa9/0xff0 kernel/hung_task.c:500
kthread+0x711/0x8a0 kernel/kthread.c:463
ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 UID: 0 PID: 6107 Comm: syz.3.20 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
RIP: 0010:kasan_check_range+0x1d4/0x2c0 mm/kasan/generic.c:200
Code: 01 f3 49 8d 5c 24 07 4d 85 e4 49 0f 49 dc 48 83 e3 f8 49 29 dc 74 12 41 80 3b 00 0f 85 b8 00 00 00 49 ff c3 49 ff cc 75 ee 5b <41> 5c 41 5d 41 5e 41 5f 5d e9 4e d8 2e 09 cc 45 84 ff 75 63 41 f7
RSP: 0018:ffffc9000383f7b0 EFLAGS: 00000256
RAX: ffffffff82431501 RBX: 0000000000000018 RCX: ffffffff824315fd
RDX: 0000000000000001 RSI: 0000000000000018 RDI: ffffc9000383f880
RBP: 0000000000000000 R08: ffffc9000383f897 R09: 1ffff92000707f12
R10: dffffc0000000000 R11: fffff52000707f13 R12: 0000000000000003
R13: ffff888079527128 R14: fffff52000707f13 R15: 1ffff92000707f10
FS: 00007f4e567906c0(0000) GS:ffff888125cdc000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055db9a726918 CR3: 000000002ec48000 CR4: 00000000003526f0
Call Trace:
<TASK>
__asan_memset+0x22/0x50 mm/kasan/shadow.c:84
seq_printf+0xad/0x270 fs/seq_file.c:403
__io_uring_show_fdinfo io_uring/fdinfo.c:142 [inline]
io_uring_show_fdinfo+0x734/0x17d0 io_uring/fdinfo.c:256
seq_show+0x5bc/0x730 fs/proc/fd.c:68
seq_read_iter+0x4ef/0xe20 fs/seq_file.c:230
seq_read+0x369/0x480 fs/seq_file.c:162
vfs_read+0x200/0xa30 fs/read_write.c:570
ksys_read+0x145/0x250 fs/read_write.c:715
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4e5598efc9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4e56790038 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 00007f4e55be6090 RCX: 00007f4e5598efc9
RDX: 0000000000002020 RSI: 00002000000040c0 RDI: 0000000000000004
RBP: 00007f4e55a11f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f4e55be6128 R14: 00007f4e55be6090 R15: 00007ffd5d16a678
</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
Oct 27, 2025, 6:04:09 PM (2 days ago) Oct 27
to syzbot, io-u...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, Keith Busch
On 10/27/25 3:07 PM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 72fb0170ef1f Add linux-next specific files for 20251024
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13087be2580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e812d103f45aa955
> dashboard link: https://syzkaller.appspot.com/bug?extid=10a9b495f54a17b607a6
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14725d2f980000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11233b04580000
[snip]
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 72fb0170ef1f Add linux-next specific files for 20251024
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13087be2580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e812d103f45aa955
> dashboard link: https://syzkaller.appspot.com/bug?extid=10a9b495f54a17b607a6
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14725d2f980000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11233b04580000
> RAX: ffffffff82431501 RBX: 0000000000000018 RCX: ffffffff824315fd
> RDX: 0000000000000001 RSI: 0000000000000018 RDI: ffffc9000383f880
> RBP: 0000000000000000 R08: ffffc9000383f897 R09: 1ffff92000707f12
> R10: dffffc0000000000 R11: fffff52000707f13 R12: 0000000000000003
> R13: ffff888079527128 R14: fffff52000707f13 R15: 1ffff92000707f10
> FS: 00007f4e567906c0(0000) GS:ffff888125cdc000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055db9a726918 CR3: 000000002ec48000 CR4: 00000000003526f0
> Call Trace:
> <TASK>
> __asan_memset+0x22/0x50 mm/kasan/shadow.c:84
> seq_printf+0xad/0x270 fs/seq_file.c:403
> __io_uring_show_fdinfo io_uring/fdinfo.c:142 [inline]
> io_uring_show_fdinfo+0x734/0x17d0 io_uring/fdinfo.c:256
> seq_show+0x5bc/0x730 fs/proc/fd.c:68
> seq_read_iter+0x4ef/0xe20 fs/seq_file.c:230
> seq_read+0x369/0x480 fs/seq_file.c:162
> vfs_read+0x200/0xa30 fs/read_write.c:570
> ksys_read+0x145/0x250 fs/read_write.c:715
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
commit 1cba30bf9fdd6c982708f3587f609a30c370d889
Author: Keith Busch <kbu...@kernel.org>
Date: Thu Oct 16 11:09:38 2025 -0700
io_uring: add support for IORING_SETUP_SQE_MIXED
leaves fdinfo open up to being broken. Before, we had:
sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
as a cap for the loop, now you just have:
while (sq_head < sq_tail) {
which seems like a bad idea. It's also missing an sq_head increment if
we hit this condition:
if (sq_idx > sq_mask)
continue;
which is also something you can trigger, and which would also end up in
an infinite loop.
Totally untested, but how about something like the below:
diff --git a/io_uring/fdinfo.c b/io_uring/fdinfo.c
index 7fb900f1d8f6..3f254ae0ad61 100644
--- a/io_uring/fdinfo.c
+++ b/io_uring/fdinfo.c
@@ -66,6 +66,7 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
unsigned int cq_head = READ_ONCE(r->cq.head);
unsigned int cq_tail = READ_ONCE(r->cq.tail);
unsigned int sq_shift = 0;
+ unsigned int sq_entries;
int sq_pid = -1, sq_cpu = -1;
u64 sq_total_time = 0, sq_work_time = 0;
unsigned int i;
@@ -88,17 +89,18 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
seq_printf(m, "CqTail:\t%u\n", cq_tail);
seq_printf(m, "CachedCqTail:\t%u\n", data_race(ctx->cached_cq_tail));
seq_printf(m, "SQEs:\t%u\n", sq_tail - sq_head);
- while (sq_head < sq_tail) {
+ sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
+ for (i = 0; i < sq_entries; i++) {
+ unsigned int entry = i + sq_head;
struct io_uring_sqe *sqe;
unsigned int sq_idx;
bool sqe128 = false;
u8 opcode;
if (ctx->flags & IORING_SETUP_NO_SQARRAY)
- sq_idx = sq_head & sq_mask;
+ sq_idx = entry & sq_mask;
else
- sq_idx = READ_ONCE(ctx->sq_array[sq_head & sq_mask]);
-
+ sq_idx = READ_ONCE(ctx->sq_array[entry & sq_mask]);
if (sq_idx > sq_mask)
continue;
@@ -140,7 +142,6 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
}
}
seq_printf(m, "\n");
- sq_head++;
}
seq_printf(m, "CQEs:\t%u\n", cq_tail - cq_head);
while (cq_head < cq_tail) {
--
Jens Axboe
Hillf Danton
Oct 27, 2025, 6:25:15 PM (2 days ago) Oct 27
to syzbot, Jens Axboe, io-u...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, Keith Busch
On Mon, 27 Oct 2025 16:04:05 -0600 Jens Axboe wrote:
> On 10/27/25 3:07 PM, syzbot wrote:
> On 10/27/25 3:07 PM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: 72fb0170ef1f Add linux-next specific files for 20251024
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=13087be2580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=e812d103f45aa955
> > dashboard link: https://syzkaller.appspot.com/bug?extid=10a9b495f54a17b607a6
> > compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14725d2f980000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11233b04580000
>
> [snip]
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: 72fb0170ef1f Add linux-next specific files for 20251024
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=13087be2580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=e812d103f45aa955
> > dashboard link: https://syzkaller.appspot.com/bug?extid=10a9b495f54a17b607a6
> > compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14725d2f980000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11233b04580000
>
>
> > RAX: ffffffff82431501 RBX: 0000000000000018 RCX: ffffffff824315fd
> > RDX: 0000000000000001 RSI: 0000000000000018 RDI: ffffc9000383f880
> > RBP: 0000000000000000 R08: ffffc9000383f897 R09: 1ffff92000707f12
> > R10: dffffc0000000000 R11: fffff52000707f13 R12: 0000000000000003
> > R13: ffff888079527128 R14: fffff52000707f13 R15: 1ffff92000707f10
> > FS: 00007f4e567906c0(0000) GS:ffff888125cdc000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 000055db9a726918 CR3: 000000002ec48000 CR4: 00000000003526f0
> > Call Trace:
> > <TASK>
> > __asan_memset+0x22/0x50 mm/kasan/shadow.c:84
> > seq_printf+0xad/0x270 fs/seq_file.c:403
> > __io_uring_show_fdinfo io_uring/fdinfo.c:142 [inline]
> > io_uring_show_fdinfo+0x734/0x17d0 io_uring/fdinfo.c:256
> > seq_show+0x5bc/0x730 fs/proc/fd.c:68
> > seq_read_iter+0x4ef/0xe20 fs/seq_file.c:230
> > seq_read+0x369/0x480 fs/seq_file.c:162
> > vfs_read+0x200/0xa30 fs/read_write.c:570
> > ksys_read+0x145/0x250 fs/read_write.c:715
> > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> > do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> > RAX: ffffffff82431501 RBX: 0000000000000018 RCX: ffffffff824315fd
> > RDX: 0000000000000001 RSI: 0000000000000018 RDI: ffffc9000383f880
> > RBP: 0000000000000000 R08: ffffc9000383f897 R09: 1ffff92000707f12
> > R10: dffffc0000000000 R11: fffff52000707f13 R12: 0000000000000003
> > R13: ffff888079527128 R14: fffff52000707f13 R15: 1ffff92000707f10
> > FS: 00007f4e567906c0(0000) GS:ffff888125cdc000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 000055db9a726918 CR3: 000000002ec48000 CR4: 00000000003526f0
> > Call Trace:
> > <TASK>
> > __asan_memset+0x22/0x50 mm/kasan/shadow.c:84
> > seq_printf+0xad/0x270 fs/seq_file.c:403
> > __io_uring_show_fdinfo io_uring/fdinfo.c:142 [inline]
> > io_uring_show_fdinfo+0x734/0x17d0 io_uring/fdinfo.c:256
> > seq_show+0x5bc/0x730 fs/proc/fd.c:68
> > seq_read_iter+0x4ef/0xe20 fs/seq_file.c:230
> > seq_read+0x369/0x480 fs/seq_file.c:162
> > vfs_read+0x200/0xa30 fs/read_write.c:570
> > ksys_read+0x145/0x250 fs/read_write.c:715
> > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> > do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Keith, I'm pretty sure your change:
>
> commit 1cba30bf9fdd6c982708f3587f609a30c370d889
> Author: Keith Busch <kbu...@kernel.org>
> Date: Thu Oct 16 11:09:38 2025 -0700
>
> io_uring: add support for IORING_SETUP_SQE_MIXED
>
> leaves fdinfo open up to being broken. Before, we had:
>
> sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
>
> as a cap for the loop, now you just have:
>
> while (sq_head < sq_tail) {
>
> which seems like a bad idea. It's also missing an sq_head increment if
> we hit this condition:
>
> if (sq_idx > sq_mask)
> continue;
>
> which is also something you can trigger, and which would also end up in
> an infinite loop.
Test Jens's fix.
>
> commit 1cba30bf9fdd6c982708f3587f609a30c370d889
> Author: Keith Busch <kbu...@kernel.org>
> Date: Thu Oct 16 11:09:38 2025 -0700
>
> io_uring: add support for IORING_SETUP_SQE_MIXED
>
> leaves fdinfo open up to being broken. Before, we had:
>
> sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
>
> as a cap for the loop, now you just have:
>
> while (sq_head < sq_tail) {
>
> which seems like a bad idea. It's also missing an sq_head increment if
> we hit this condition:
>
> if (sq_idx > sq_mask)
> continue;
>
> which is also something you can trigger, and which would also end up in
> an infinite loop.
#syz test
Jens Axboe
Oct 27, 2025, 7:16:01 PM (2 days ago) Oct 27
to Keith Busch, syzbot, io-u...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
On 10/27/25 4:57 PM, Keith Busch wrote:
> right?
Right, it's a malicious use case. But you always have to be able to deal
with those, it's not like broken hardware in that sense.
> Regardless, I messed up and the wrong thing will happen here in
> that case as well as the one you mentioned.
Yep I think so too, was more interested in your opinion on the patch :-)
--
Jens Axboe
> On Mon, Oct 27, 2025 at 04:04:05PM -0600, Jens Axboe wrote:
>>
>> commit 1cba30bf9fdd6c982708f3587f609a30c370d889
>> Author: Keith Busch <kbu...@kernel.org>
>> Date: Thu Oct 16 11:09:38 2025 -0700
>>
>> io_uring: add support for IORING_SETUP_SQE_MIXED
>>
>> leaves fdinfo open up to being broken. Before, we had:
>>
>> sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
>>
>> as a cap for the loop, now you just have:
>>
>> while (sq_head < sq_tail) {
>>
>> which seems like a bad idea. It's also missing an sq_head increment if
>> we hit this condition:
>
> This would have to mean the application did an invalid head ring-wrap,
>>
>> commit 1cba30bf9fdd6c982708f3587f609a30c370d889
>> Author: Keith Busch <kbu...@kernel.org>
>> Date: Thu Oct 16 11:09:38 2025 -0700
>>
>> io_uring: add support for IORING_SETUP_SQE_MIXED
>>
>> leaves fdinfo open up to being broken. Before, we had:
>>
>> sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
>>
>> as a cap for the loop, now you just have:
>>
>> while (sq_head < sq_tail) {
>>
>> which seems like a bad idea. It's also missing an sq_head increment if
>> we hit this condition:
>
> right?
Right, it's a malicious use case. But you always have to be able to deal
with those, it's not like broken hardware in that sense.
> Regardless, I messed up and the wrong thing will happen here in
> that case as well as the one you mentioned.
Yep I think so too, was more interested in your opinion on the patch :-)
--
Jens Axboe
syzbot
Oct 27, 2025, 8:15:04 PM (2 days ago) Oct 27
to ax...@kernel.dk, hda...@sina.com, io-u...@vger.kernel.org, kbu...@kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-by: syzbot+10a9b4...@syzkaller.appspotmail.com
Tested-by: syzbot+10a9b4...@syzkaller.appspotmail.com
Tested on:
commit: 8fec172c Add linux-next specific files for 20251027
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=140bac92580000
kernel config: https://syzkaller.appspot.com/x/.config?x=9da2d5fce59079e1
Note: testing is done by a robot and is best-effort only.
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-by: syzbot+10a9b4...@syzkaller.appspotmail.com
Tested-by: syzbot+10a9b4...@syzkaller.appspotmail.com
Tested on:
commit: 8fec172c Add linux-next specific files for 20251027
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=140bac92580000
kernel config: https://syzkaller.appspot.com/x/.config?x=9da2d5fce59079e1
dashboard link: https://syzkaller.appspot.com/bug?extid=10a9b495f54a17b607a6
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=148753cd980000
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
Note: testing is done by a robot and is best-effort only.
Jens Axboe
Oct 27, 2025, 9:09:13 PM (2 days ago) Oct 27
to Keith Busch, syzbot, io-u...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
On 10/27/25 6:03 PM, Keith Busch wrote:
Thanks for checking! I'll send it out.
> I plowed through this thinking the mixed CQE
> showed the way, but didn't appreciate the subtle differences on the
> submission side.
Ah right, yes on the CQ side the kernel controls it as the producer. No
such risk there.
--
Jens Axboe
> On Mon, Oct 27, 2025 at 05:15:56PM -0600, Jens Axboe wrote:
>>>> leaves fdinfo open up to being broken. Before, we had:
>>>>
>>>> sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
>>>>
>>>> as a cap for the loop, now you just have:
>>>>
>>>> while (sq_head < sq_tail) {
>>>>
>>>> which seems like a bad idea. It's also missing an sq_head increment if
>>>> we hit this condition:
>>>
>>> This would have to mean the application did an invalid head ring-wrap,
>>> right?
>>
>> Right, it's a malicious use case. But you always have to be able to deal
>> with those, it's not like broken hardware in that sense.
>>
>>> Regardless, I messed up and the wrong thing will happen here in
>>> that case as well as the one you mentioned.
>>
>> Yep I think so too, was more interested in your opinion on the patch :-)
>
> Yeah, patch looks good.
>>>> leaves fdinfo open up to being broken. Before, we had:
>>>>
>>>> sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
>>>>
>>>> as a cap for the loop, now you just have:
>>>>
>>>> while (sq_head < sq_tail) {
>>>>
>>>> which seems like a bad idea. It's also missing an sq_head increment if
>>>> we hit this condition:
>>>
>>> This would have to mean the application did an invalid head ring-wrap,
>>> right?
>>
>> Right, it's a malicious use case. But you always have to be able to deal
>> with those, it's not like broken hardware in that sense.
>>
>>> Regardless, I messed up and the wrong thing will happen here in
>>> that case as well as the one you mentioned.
>>
>> Yep I think so too, was more interested in your opinion on the patch :-)
>
Thanks for checking! I'll send it out.
> I plowed through this thinking the mixed CQE
> showed the way, but didn't appreciate the subtle differences on the
> submission side.
Ah right, yes on the CQ side the kernel controls it as the producer. No
such risk there.
--
Jens Axboe
Keith Busch
Oct 28, 2025, 9:43:33 AM (yesterday) Oct 28
to Jens Axboe, syzbot, io-u...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
On Mon, Oct 27, 2025 at 05:15:56PM -0600, Jens Axboe wrote:
> >> leaves fdinfo open up to being broken. Before, we had:
> >>
> >> sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
> >>
> >> as a cap for the loop, now you just have:
> >>
> >> while (sq_head < sq_tail) {
> >>
> >> which seems like a bad idea. It's also missing an sq_head increment if
> >> we hit this condition:
> >
> > This would have to mean the application did an invalid head ring-wrap,
> > right?
>
> Right, it's a malicious use case. But you always have to be able to deal
> with those, it's not like broken hardware in that sense.
>
> > Regardless, I messed up and the wrong thing will happen here in
> > that case as well as the one you mentioned.
>
> Yep I think so too, was more interested in your opinion on the patch :-)
Yeah, patch looks good. I plowed through this thinking the mixed CQE
> >>
> >> sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
> >>
> >> as a cap for the loop, now you just have:
> >>
> >> while (sq_head < sq_tail) {
> >>
> >> which seems like a bad idea. It's also missing an sq_head increment if
> >> we hit this condition:
> >
> > This would have to mean the application did an invalid head ring-wrap,
> > right?
>
> Right, it's a malicious use case. But you always have to be able to deal
> with those, it's not like broken hardware in that sense.
>
> > Regardless, I messed up and the wrong thing will happen here in
> > that case as well as the one you mentioned.
>
> Yep I think so too, was more interested in your opinion on the patch :-)
Keith Busch
Oct 28, 2025, 9:43:33 AM (yesterday) Oct 28
to Jens Axboe, syzbot, io-u...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com
On Mon, Oct 27, 2025 at 04:04:05PM -0600, Jens Axboe wrote:
>
>
> commit 1cba30bf9fdd6c982708f3587f609a30c370d889
> Author: Keith Busch <kbu...@kernel.org>
> Date: Thu Oct 16 11:09:38 2025 -0700
>
> io_uring: add support for IORING_SETUP_SQE_MIXED
>
> leaves fdinfo open up to being broken. Before, we had:
>
> sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
>
> as a cap for the loop, now you just have:
>
> while (sq_head < sq_tail) {
>
> which seems like a bad idea. It's also missing an sq_head increment if
> we hit this condition:
> Author: Keith Busch <kbu...@kernel.org>
> Date: Thu Oct 16 11:09:38 2025 -0700
>
> io_uring: add support for IORING_SETUP_SQE_MIXED
>
> leaves fdinfo open up to being broken. Before, we had:
>
> sq_entries = min(sq_tail - sq_head, ctx->sq_entries);
>
> as a cap for the loop, now you just have:
>
> while (sq_head < sq_tail) {
>
> which seems like a bad idea. It's also missing an sq_head increment if
> we hit this condition:
This would have to mean the application did an invalid head ring-wrap,
right? Regardless, I messed up and the wrong thing will happen here in
Reply all
Reply to author
Forward
0 new messages