[syzbot] [block?] [ext4?] BUG: unable to handle kernel paging request in blk_mq_exit_hctx

[syzbot] [block?] [ext4?] BUG: unable to handle kernel paging request in blk_mq_exit_hctx

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    7a19f0cc94ad Merge branch 'for-next/core' into for-kernelci
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=17bddc8d580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=6602d83d2f34eb80
dashboard link: https://syzkaller.appspot.com/bug?extid=5307e3bcacec2ce4c2f0
compiler:       Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
userspace arch: arm64
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=169be5a5580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/26f2e4202da9/disk-7a19f0cc.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/1e23a9081d19/vmlinux-7a19f0cc.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b51f551829ee/Image-7a19f0cc.gz.xz
mounted in repro #1: https://storage.googleapis.com/syzbot-assets/f7427d1d35bc/mount_4.gz
  fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=15bddc8d580000)
mounted in repro #2: https://storage.googleapis.com/syzbot-assets/22e8d60714f9/mount_5.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=11dc1d29580000)
mounted in repro #3: https://storage.googleapis.com/syzbot-assets/f50f15fd78d0/mount_20.gz
  fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=13ab1795580000)
mounted in repro #4: https://storage.googleapis.com/syzbot-assets/3cdc94810dc2/mount_21.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=13bddc8d580000)

AI-generated root cause summary:
When dm_setup_md_queue() fails after add_disk() (for instance during
bd_link_disk_holder() or dm_sysfs_init()), the error path invokes del_gendisk(),
which calls blk_mq_exit_queue() -> blk_mq_exit_hctx(), freeing each hardware
context flush queue and setting hctx->fq = NULL. However, md->type remains
DM_TYPE_NONE and the mapped device is not torn down. When userspace retries
table_load on the device, dm_setup_md_queue() and dm_mq_init_request_queue() run
again, invoking blk_mq_init_allocated_queue() on the existing queue. During
__blk_mq_realloc_hw_ctxs(), blk_mq_exit_hctx() is called on the existing
hardware contexts, unconditionally dereferencing hctx->fq->flush_rq (offset
0x78) when hctx->fq is NULL, causing a kernel null-pointer dereference crash.

full analysis:  https://syzkaller.appspot.com/x/ai_root_cause?x=5307e3bcacec2ce4c2f0

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

Unable to handle kernel paging request at virtual address dfff80000000000f
KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]
Mem abort info:
  ESR = 0x0000000096000005
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x05: level 1 translation fault
Data abort info:
  ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
  CM = 0, WnR = 0, TnD = 0, TagAccess = 0
  GCS = 0, Overlay = 0, DirtyBit = 0
[dfff80000000000f] address between user and kernel address ranges
Internal error: Oops: 0000000096000005 [#1]  SMP
Modules linked in:
CPU: 0 UID: 0 PID: 9108 Comm: syz.5.600 Not tainted syzkaller #0 PREEMPT 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/14/2026
pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : blk_mq_exit_hctx+0x64/0x494 block/blk-mq.c:3957
lr : blk_mq_exit_hctx+0x40/0x494 block/blk-mq.c:3956
sp : ffff8000984475d0
x29: ffff8000984475e0 x28: 0000000000000000 x27: 1fffe0001b03332a
x26: dfff800000000000 x25: ffff0000d8199950 x24: ffff0000c3aeffc0
x23: 0000000000000078 x22: 0000000000000000 x21: ffff0000d3857000
x20: ffff0000d8199800 x19: ffff0000eabc5388 x18: ffff8001237ae000
x17: ffff0001acf6ce07 x16: ffff0000dad68014 x15: 0000000000000001
x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: ffff0000eabc53bc x9 : 0000000000000000
x8 : 000000000000000f x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000003 x3 : 0000000000000000
x2 : ffff0000d8199800 x1 : ffff0000dad68000 x0 : 0000000000000000
Call trace:
 blk_mq_exit_hctx+0x64/0x494 block/blk-mq.c:3957 (P)
 __blk_mq_realloc_hw_ctxs+0x1f0/0x548 block/blk-mq.c:4583
 blk_mq_realloc_hw_ctxs block/blk-mq.c:4623 [inline]
 blk_mq_init_allocated_queue+0x2a8/0xc44 block/blk-mq.c:4653
 dm_mq_init_request_queue+0x2d8/0x474 drivers/md/dm-rq.c:573
 dm_setup_md_queue+0x134/0x434 drivers/md/dm.c:2611
 table_load+0x3d4/0x764 drivers/md/dm-ioctl.c:1661
 ctl_ioctl drivers/md/dm-ioctl.c:2221 [inline]
 dm_ctl_ioctl+0x884/0xbbc drivers/md/dm-ioctl.c:2243
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:597 [inline]
 __se_sys_ioctl fs/ioctl.c:583 [inline]
 __arm64_sys_ioctl+0x154/0x1cc fs/ioctl.c:583
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall+0x98/0x244 arch/arm64/kernel/syscall.c:49
 el0_svc_common+0xec/0x23c arch/arm64/kernel/syscall.c:121
 do_el0_svc+0x4c/0x5c arch/arm64/kernel/syscall.c:140
 el0_svc+0x60/0x1d8 arch/arm64/kernel/entry-common.c:796
 el0t_64_sync_handler+0x44/0x104 arch/arm64/kernel/entry-common.c:815
 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:606
Code: 97cfdb27 f9400328 9101e117 d343fee8 (387a6908) 
---[ end trace 0000000000000000 ]---
----------------
Code disassembly (best guess):
   0:	97cfdb27 	bl	0xffffffffff3f6c9c
   4:	f9400328 	ldr	x8, [x25]
   8:	9101e117 	add	x23, x8, #0x78
   c:	d343fee8 	lsr	x8, x23, #3
* 10:	387a6908 	ldrb	w8, [x8, x26] <-- trapping instruction


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