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 <[email protected]>
dm-setup-md-queue-uaf-repro.tar.gz
Description: GNU Zip compressed data
