[syzbot] [nvme?] KASAN: slab-out-of-bounds Read in nvmet_install_queue

[syzbot] [nvme?] KASAN: slab-out-of-bounds Read in nvmet_install_queue

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    848acc8ffe1b Merge tag 'fsverity-for-linus' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12cb8bb9580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=145fa60d73086782
dashboard link: https://syzkaller.appspot.com/bug?extid=2626e846cd2585c9aa67
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-848acc8f.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/6fb497cc0c8d/vmlinux-848acc8f.xz
kernel image: https://storage.googleapis.com/syzbot-assets/663ccee34982/bzImage-848acc8f.xz

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

==================================================================
BUG: KASAN: slab-out-of-bounds in nvmet_install_queue+0x522/0x590 drivers/nvme/target/fabrics-cmd.c:189
Read of size 8 at addr ffff888058219a70 by task kworker/u33:8/1166

CPU: 1 UID: 0 PID: 1166 Comm: kworker/u33:8 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
Workqueue: nvmet-wq nvme_loop_execute_work
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0x13d/0x4b0 mm/kasan/report.c:482
 kasan_report+0xdf/0x1c0 mm/kasan/report.c:595
 nvmet_install_queue+0x522/0x590 drivers/nvme/target/fabrics-cmd.c:189
 nvmet_execute_io_connect+0x294/0x490 drivers/nvme/target/fabrics-cmd.c:380
 process_one_work+0xa23/0x1940 kernel/workqueue.c:3322
 process_scheduled_works kernel/workqueue.c:3405 [inline]
 worker_thread+0x5ef/0xe50 kernel/workqueue.c:3486
 kthread+0x370/0x450 kernel/kthread.c:436
 ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

Allocated by task 1174:
 kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
 kasan_save_track+0x14/0x30 mm/kasan/common.c:78
 poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
 __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
 kasan_kmalloc include/linux/kasan.h:263 [inline]
 __do_kmalloc_node mm/slub.c:5334 [inline]
 __kmalloc_noprof+0x322/0x820 mm/slub.c:5359
 _kmalloc_noprof include/linux/slab.h:992 [inline]
 _kzalloc_noprof include/linux/slab.h:1309 [inline]
 nvmet_alloc_ctrl+0x9c2/0x1560 drivers/nvme/target/core.c:1655
 nvmet_execute_admin_connect+0x3c3/0x5b0 drivers/nvme/target/fabrics-cmd.c:317
 process_one_work+0xa23/0x1940 kernel/workqueue.c:3322
 process_scheduled_works kernel/workqueue.c:3405 [inline]
 worker_thread+0x5ef/0xe50 kernel/workqueue.c:3486
 kthread+0x370/0x450 kernel/kthread.c:436
 ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

The buggy address belongs to the object at ffff888058219a60
 which belongs to the cache kmalloc-16 of size 16
The buggy address is located 0 bytes to the right of
 allocated 16-byte region [ffff888058219a60, ffff888058219a70)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888058219f80 pfn:0x58219
flags: 0xfff00000000200(workingset|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000200 ffff88801bc42640 ffffea000169a050 ffffea00015fa390
raw: ffff888058219f80 000000080080007f 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5739, tgid 5739 (syz-executor), ts 50610714726, free_ts 49976327990
 create_dummy_stack mm/page_owner.c:103 [inline]
 register_dummy_stack+0x74/0xb0 mm/page_owner.c:109
 init_page_owner+0x42/0xa10 mm/page_owner.c:127
 invoke_init_callbacks mm/page_ext.c:152 [inline]
 page_ext_init+0x71d/0x780 mm/page_ext.c:490
 mm_core_init+0x229/0x270 mm/mm_init.c:2748
page last free pid 33 tgid 33 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1406 [inline]
 __free_frozen_pages+0x79f/0x1090 mm/page_alloc.c:2950
 __pagetable_free include/linux/mm.h:3695 [inline]
 pagetable_free include/linux/mm.h:3719 [inline]
 pagetable_dtor_free include/linux/mm.h:3818 [inline]
 __tlb_remove_table include/asm-generic/tlb.h:221 [inline]
 __tlb_remove_table_free mm/mmu_gather.c:228 [inline]
 tlb_remove_table_rcu+0x2cf/0x380 mm/mmu_gather.c:291
 rcu_do_batch kernel/rcu/tree.c:2645 [inline]
 rcu_core+0x5a2/0x10d0 kernel/rcu/tree.c:2897
 handle_softirqs+0x1ea/0x9b0 kernel/softirq.c:622
 run_ksoftirqd kernel/softirq.c:1076 [inline]
 run_ksoftirqd+0x38/0x60 kernel/softirq.c:1068
 smpboot_thread_fn+0x3d3/0xaa0 kernel/smpboot.c:160
 kthread+0x370/0x450 kernel/kthread.c:436
 ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Memory state around the buggy address:
 ffff888058219900: fa fb fc fc fa fb fc fc fa fb fc fc fa fb fc fc
 ffff888058219980: fa fb fc fc fa fb fc fc fa fb fc fc 00 02 fc fc
>ffff888058219a00: 00 00 fc fc fa fb fc fc fa fb fc fc 00 00 fc fc
                                                             ^
 ffff888058219a80: fa fb fc fc fa fb fc fc fa fb fc fc 00 00 fc fc
 ffff888058219b00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
==================================================================


---
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 syzkaller@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 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

Re: [syzbot] [nvme?] KASAN: slab-out-of-bounds Read in nvmet_install_queue

[Maurizio Lombardi]

On Fri Aug 7, 2026 at 2:01 AM CEST, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
>
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in nvmet_install_queue+0x522/0x590 drivers/nvme/target/fabrics-cmd.c:189
> Read of size 8 at addr ffff888058219a70 by task kworker/u33:8/1166
>
> CPU: 1 UID: 0 PID: 1166 Comm: kworker/u33:8 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
> Workqueue: nvmet-wq nvme_loop_execute_work
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:94 [inline]
>  dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
>  print_address_description mm/kasan/report.c:378 [inline]
>  print_report+0x13d/0x4b0 mm/kasan/report.c:482
>  kasan_report+0xdf/0x1c0 mm/kasan/report.c:595
>  nvmet_install_queue+0x522/0x590 drivers/nvme/target/fabrics-cmd.c:189
>  nvmet_execute_io_connect+0x294/0x490 drivers/nvme/target/fabrics-cmd.c:380

I am able to reproduce it, the problem is that
nvmet_subsys_attr_qid_max_store() can race against
nvmet_alloc_control().

Suppose max_qid is 64.
nvmet_alloc_ctrl() executed ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1);

at this point a userspace process changes max_qid to 128.
nvmet_subsys_attr_qid_max_store() sets the new max_qid value but
the new controller won't be deleted because it hasn't been added to the
subsys->ctrls list yet.


nvmet_alloc_ctrl() proceeds and adds the new controller to the
subsys->ctrls list.

Now nvmet_install_queue() will be called with max_qid set to 128, but
the memory allocated for sqs is just for 64 entries, hence the KASAN
warning.

I will try to prepare a patch.

Maurizio