Hello, I am reporting unbounded recursion in dm_blk_ioctl(): it forwards a block ioctl to the underlying device with no depth or cycle guard. A two-device DM-on-DM cycle then re-enters dm_blk_ioctl until the kernel stack is exhausted.
Summary ======= dm_prepare_ioctl() lets the single target substitute bdev via prepare_ioctl. dm_blk_ioctl() then calls that disk's fops->ioctl with the original cmd/arg: r = dm_prepare_ioctl(md, &srcu_idx, &bdev); ... r = bdev->bd_disk->fops->ioctl(bdev, mode, cmd, arg); linear_prepare_ioctl / flakey_prepare_ioctl just set *bdev to the underlying device when sizes match. When that device is another DM disk, fops->ioctl is dm_blk_ioctl again. Table load rejects only a device mapped onto itself (dm_get_device: dev == disk_devt(t->md->disk)). A->B->A is accepted. bd_link_disk_holder rejects only a disk holding itself. Ordinary BLKGETSIZE* ioctls on the same cycle return cleanly (handled in the block layer). A DM-style ioctl (DM_VERSION) on the mapped block fd is not handled there and is forwarded unbounded. The shipped PoC uses linear + flakey. linear<->linear is expected to recurse the same way via linear_prepare_ioctl. Affected ======== - Confirmed on Linux 6.6.144 (da47cbc254661aa66d61ef061485a7080305c4be), stack-protector guest - Still present on torvalds/linux master as of 2026-08-18: dm_blk_ioctl still forwards with no depth/cycle check; dm_get_device still only rejects self-map. The later prepare_ioctl forward flag is for target-local handling, not cycle detection (linear still always forwards) - Files: drivers/md/dm.c, drivers/md/dm-linear.c, drivers/md/dm-table.c - Config: CONFIG_DM=y (CONFIG_DM_FLAKEY=y for the shipped PoC topology) Crash excerpt (from minimized PoC) ================================== BUG: TASK stack guard page was hit at ... CPU: 0 PID: 219 Comm: repro Not tainted 6.6.144 #1 RIP: 0010:dm_prepare_ioctl+0x10/0x100 Call Trace: <TASK> dm_blk_ioctl+0x4d/0xe0 dm_blk_ioctl+0x78/0xe0 dm_blk_ioctl+0x78/0xe0 ... (dozens more recursive dm_blk_ioctl frames) </TASK> Kernel panic - not syncing: Fatal exception Full oops and a self-contained Docker/QEMU reproducer (poc.c) are available on request. I am happy to test patches or send the reproducer package. Thanks, Yu Junzhe FuzzAnything <[email protected]>
