[BUG] dm: dm_setup_md_queue UAF walking table_devices without lock

[BUG] dm: dm_setup_md_queue UAF walking table_devices without lock

[Junzhe Yu]

[-- Attachment #1: Type: text/plain, Size: 3138 bytes --]

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

[-- Attachment #2: dm-setup-md-queue-uaf-repro.tar.gz --]
[-- Type: application/x-gzip, Size: 9683 bytes --]

Re: [BUG] dm: dm_setup_md_queue UAF walking table_devices without lock

[Mikulas Patocka]

On Sat, 18 Jul 2026, Junzhe Yu wrote:

> 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().

Hi

Does this patch fix it?

Mikulas



dm: fix race when loading and unloading a table

If the userspace calls two concurrent table load ioctls and one of them
succeeds and the other fails, there is a race condition because
dm_setup_md_queue walks &md->table_devices without any lock. If the walk
races with dm_table_destroy -> free_devices -> dm_put_table_device, there
is access to invalid memory.

Fix this race by extending the lock over the list walk.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org

---
 drivers/md/dm.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

Index: linux-2.6/drivers/md/dm.c
===================================================================
--- linux-2.6.orig/drivers/md/dm.c	2026-07-23 14:13:37.000000000 +0200
+++ linux-2.6/drivers/md/dm.c	2026-07-23 18:43:19.000000000 +0200
@@ -2630,9 +2630,10 @@ int dm_setup_md_queue(struct mapped_devi
 	 */
 	mutex_lock(&md->table_devices_lock);
 	r = add_disk(md->disk);
-	mutex_unlock(&md->table_devices_lock);
-	if (r)
+	if (r) {
+		mutex_unlock(&md->table_devices_lock);
 		return r;
+	}
 
 	/*
 	 * Register the holder relationship for devices added before the disk
@@ -2643,18 +2644,21 @@ int dm_setup_md_queue(struct mapped_devi
 		if (r)
 			goto out_undo_holders;
 	}
+	mutex_unlock(&md->table_devices_lock);
 
 	r = dm_sysfs_init(md);
 	if (r)
-		goto out_undo_holders;
+		goto lock_out_undo_holders;
 
 	md->type = type;
+
 	return 0;
 
+lock_out_undo_holders:
+	mutex_lock(&md->table_devices_lock);
 out_undo_holders:
 	list_for_each_entry_continue_reverse(td, &md->table_devices, list)
 		bd_unlink_disk_holder(td->dm_dev.bdev, md->disk);
-	mutex_lock(&md->table_devices_lock);
 	del_gendisk(md->disk);
 	mutex_unlock(&md->table_devices_lock);
 	return r;

Re: [BUG] dm: dm_setup_md_queue UAF walking table_devices without lock

[Junzhe Yu]

[-- Attachment #1: Type: text/plain, Size: 3429 bytes --]

Hi Mikulas,

Thanks for the suggested fix. We verified it on Linux 6.6.144 with KASAN
against our minimized PoC (concurrent DM_TABLE_LOAD racing
dm_setup_md_queue's unlocked table_devices walk).

Results:
   - unpatched: KASAN slab-use-after-free in dm_setup_md_queue (often with
     a follow-on fault around bd_link_disk_holder)
   - with your change (extend table_devices_lock over the list walk):
     no KASAN UAF for a 5-minute PoC window

Self-contained test package (patch + poc.c + A/B scripts + captured logs):

   dm-setup-md-queue-patch-test.tar.gz

Re-run with Docker (see README.md inside the tarball):

   docker build -t dm-setup-md-queue-patch-test -f Dockerfile .
   mkdir -p artifacts
   docker run --rm --privileged --device=/dev/kvm --network=host \
     -v "$PWD/artifacts:/artifacts" -e OUTPUT_DIR=/artifacts \
     dm-setup-md-queue-patch-test

Happy to test follow-ups if needed.

Thanks,
Junzhe

On 7/24/2026 4:23 AM, Mikulas Patocka wrote:
>
> On Sat, 18 Jul 2026, Junzhe Yu wrote:
>
>> 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().
> Hi
>
> Does this patch fix it?
>
> Mikulas
>
>
>
> dm: fix race when loading and unloading a table
>
> If the userspace calls two concurrent table load ioctls and one of them
> succeeds and the other fails, there is a race condition because
> dm_setup_md_queue walks &md->table_devices without any lock. If the walk
> races with dm_table_destroy -> free_devices -> dm_put_table_device, there
> is access to invalid memory.
>
> Fix this race by extending the lock over the list walk.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Cc: stable@vger.kernel.org
>
> ---
>   drivers/md/dm.c |   12 ++++++++----
>   1 file changed, 8 insertions(+), 4 deletions(-)
>
> Index: linux-2.6/drivers/md/dm.c
> ===================================================================
> --- linux-2.6.orig/drivers/md/dm.c	2026-07-23 14:13:37.000000000 +0200
> +++ linux-2.6/drivers/md/dm.c	2026-07-23 18:43:19.000000000 +0200
> @@ -2630,9 +2630,10 @@ int dm_setup_md_queue(struct mapped_devi
>   	 */
>   	mutex_lock(&md->table_devices_lock);
>   	r = add_disk(md->disk);
> -	mutex_unlock(&md->table_devices_lock);
> -	if (r)
> +	if (r) {
> +		mutex_unlock(&md->table_devices_lock);
>   		return r;
> +	}
>   
>   	/*
>   	 * Register the holder relationship for devices added before the disk
> @@ -2643,18 +2644,21 @@ int dm_setup_md_queue(struct mapped_devi
>   		if (r)
>   			goto out_undo_holders;
>   	}
> +	mutex_unlock(&md->table_devices_lock);
>   
>   	r = dm_sysfs_init(md);
>   	if (r)
> -		goto out_undo_holders;
> +		goto lock_out_undo_holders;
>   
>   	md->type = type;
> +
>   	return 0;
>   
> +lock_out_undo_holders:
> +	mutex_lock(&md->table_devices_lock);
>   out_undo_holders:
>   	list_for_each_entry_continue_reverse(td, &md->table_devices, list)
>   		bd_unlink_disk_holder(td->dm_dev.bdev, md->disk);
> -	mutex_lock(&md->table_devices_lock);
>   	del_gendisk(md->disk);
>   	mutex_unlock(&md->table_devices_lock);
>   	return r;
>

[-- Attachment #2: dm-setup-md-queue-patch-test.tar.gz --]
[-- Type: application/x-gzip, Size: 12317 bytes --]