Preface: Essentially, when security experts read vulnerability lists, the priority is time-dependent. For example, if you read a CVE reference document on January 2, 2025, but the document’s starting date is 2023, there’s a 99% chance you’ll ignore it. This makes sense, after all, it’s two years ago. According to vendor practice, when patches are released, they prioritize notifying customers. The timing of public releases depends on the vendor’s policy. But what made me interested in this CVE and want to delve deeper? In fact, when you investigate further, you discover more information than expected.
You’re welcome to continue exploring.
Background: Instead of the md driver’s classic RAID, Android utilizes the Device Mapper (DM) framework—specifically the same dm-ioctl.c interface you noted earlier—to implement modern, mobile-specific storage features.
The Device Mapper framework operates within standard kernel memory space and uses the general-purpose Linux memory allocators (kmalloc, the buddy allocator, or potentially the Contiguous Memory Allocator (CMA) for large buffers).
However, seems the major remedy is implement a tool ( rw_semaphore devices_lock). When the Device Mapper drivers (dm-ioctl.c, dm-core.h, and dm-table.c) are used on an Android smartphone with a Qualcomm processor. The memory used by the storage drivers (drivers/md/) and the memory managed by the graphics drivers (Qualcomm’s KGSL) are distinct and reserved for different purposes:
Storage (Device Mapper) Memory
The Device Mapper framework operates within standard kernel memory space and uses the general-purpose Linux memory allocators (kmalloc, the buddy allocator, or potentially the Contiguous Memory Allocator (CMA) for large buffers).
- When the storage drivers perform tasks like encryption (dm-crypt) or integrity checks (dm-verity), they are processing data from the main system RAM or directly from the physical storage chip using Direct Memory Access (DMA).
- The system uses memory pools like ION or ashmem to manage shared buffers between the kernel and user-space applications for storage tasks. These are separate from GPU pools.
Vulnerability details: In the Linux kernel, the following vulnerability has been resolved.
dm: fix a race condition in retrieve_deps There’s a race condition in the multipath target when retrieve_deps races with multipath_message calling dm_get_device and dm_put_device. retrieve_deps walks the list of open devices without holding any lock but multipath may add or remove devices to the list while it is running. The end result may be memory corruption or use-after-free memory access.
See this description of a UAF with multipath_message(): https://listman.redhat.com/archives/dm-devel/2022-October/052373.html Fix this bug by introducing a new rw semaphore “devices_lock”. We grab devices_lock for read in retrieve_deps and we grab it for write in dm_get_device and dm_put_device.
Official announcement: Please refer to the link for details. https://www.tenable.com/cve/CVE-2023-54324