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

[Junzhe Yu <junzheyu1@gmail.com>]

[-- 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 --]