[BUG] dm: unbounded recursion in dm_blk_ioctl via cyclic DM stacking

[Yu Junzhe <junzheyu1@gmail.com>]

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 <fuzzanything@gmail.com>