[BUG] dm: dm_setup_md_queue UAF walking table_devices without lock

[Junzhe Yu]

Hello,

I am reporting a KASAN slab use-after-free in the device-mapper core in
dm_setup_md_queue().

Summary
=======

dm_setup_md_queue() walks md->table_devices without holding
md->table_devices_lock while a concurrent failed DM_TABLE_LOAD frees a
table_device via dm_table_destroy() -> close_table_device(). The crash
shows as a KASAN UAF on the list walk, and often a follow-on page fault
in bd_link_disk_holder().

Affected
========

- Confirmed on Linux 6.6.144 (da47cbc254661aa66d61ef061485a7080305c4be)
- Originally found on Linux 6.6.0 (ffc253263a1375a65fa6c9f62a893e9767fbebfa)
- Files: drivers/md/dm.c, drivers/md/dm-ioctl.c
- Config: CONFIG_DM=y, CONFIG_BLK_DEV_LOOP=y, CONFIG_KASAN=y

Root cause (brief)
==================

- Top frame: dm_setup_md_queue() at drivers/md/dm.c:2380
  (list_for_each_entry over md->table_devices), called from table_load()
  while md->type == DM_TYPE_NONE.
- table_devices_lock is held only around add_disk() and then released. The
  subsequent list walk that calls bd_link_disk_holder() has no lock.
- A concurrent failed table_load unlocks at err_unlock_md_type and then
  dm_table_destroy() -> close_table_device() (list_del + kfree) races with
  that walk.

The PoC uses only documented DM ioctls (DM_DEV_CREATE, DM_TABLE_LOAD,
DM_DEV_REMOVE) as root. Concurrent table loads are not forbidden by the
userspace API; the kernel must serialize mapped-device state.

Crash excerpt (KASAN)
=====================

BUG: KASAN: slab-use-after-free in dm_setup_md_queue+0x4f4/0x590
Call Trace:
 dm_setup_md_queue+0x4f4/0x590
 table_load+0x56b/0x8b0
 ctl_ioctl+0x72a/0xcb0

Allocated by: linear_ctr -> dm_get_table_device -> table_load
Freed by:     linear_dtr -> dm_table_destroy -> table_load error path

Full stack is in the attached tarball as stacktrace.txt.

Impact
======

Privileged local DoS (CAP_SYS_ADMIN required). Practical exploitation
beyond DoS has not been evaluated; reporting as a privileged memory-safety
bug / DoS in DM core.

Reproducer
==========

Attached: dm-setup-md-queue-uaf-repro.tar.gz

VM-only. Six workers race: create a fresh DM device, concurrent failing
linear table load vs successful error-target load (dm_setup_md_queue runs
while type is DM_TYPE_NONE), then remove.

Quick path (Docker + KVM):

  tar xzf dm-setup-md-queue-uaf-repro.tar.gz
  cd <extracted-dir>
  docker build -t dm-setup-md-queue-uaf -f Dockerfile .
  mkdir -p artifacts
  docker run --rm --privileged --device=/dev/kvm --network=host \
    -v "$PWD/artifacts:/artifacts" \
    -e OUTPUT_DIR=/artifacts \
    -e RUN_TIMEOUT_SEC=240 \
    dm-setup-md-queue-uaf

Expected within ~40s after the PoC starts (first run also builds the
kernel):

  BUG: KASAN: slab-use-after-free in dm_setup_md_queue
  ...
  Kernel panic - not syncing: Fatal exception

Note: a WARNING in bd_unlink_disk_holder / bd_link_disk_holder may appear
first. The attached run.sh omits panic_on_warn=1 so the guest can continue
into the KASAN UAF.

I am happy to test patches. Please let me know if you need more detail.

Thanks,
Yu Junzhe
FuzzAnything <fuzzanything@xxxxxxxxx>

Attachment: dm-setup-md-queue-uaf-repro.tar.gz
Description: GNU Zip compressed data