CVE-2025-40134 in Linux
Summary
by MITRE • 11/12/2025
In the Linux kernel, the following vulnerability has been resolved:
dm: fix NULL pointer dereference in __dm_suspend()
There is a race condition between dm device suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes:
BUG: kernel NULL pointer dereference, address: 0000000000000054 Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50 Call Trace: <TASK> blk_mq_quiesce_queue+0x2c/0x50 dm_stop_queue+0xd/0x20 __dm_suspend+0x130/0x330 dm_suspend+0x11a/0x180 dev_suspend+0x27e/0x560 ctl_ioctl+0x4cf/0x850 dm_ctl_ioctl+0xd/0x20 vfs_ioctl+0x1d/0x50 __se_sys_ioctl+0x9b/0xc0 __x64_sys_ioctl+0x19/0x30 x64_sys_call+0x2c4a/0x4620 do_syscall_64+0x9e/0x1b0
The issue can be triggered as below:
T1 T2 dm_suspend table_load __dm_suspend dm_setup_md_queue dm_mq_init_request_queue blk_mq_init_allocated_queue => q->mq_ops = set->ops; (1) dm_stop_queue / dm_wait_for_completion => q->tag_set NULL pointer! (2) => q->tag_set = set; (3)
Fix this by checking if a valid table (map) exists before performing request-based suspend and waiting for target I/O. When map is NULL, skip these table-dependent suspend steps.
Even when map is NULL, no I/O can reach any target because there is no table loaded; I/O submitted in this state will fail early in the DM layer. Skipping the table-dependent suspend logic in this case is safe and avoids NULL pointer dereferences.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/08/2026
The vulnerability CVE-2025-40134 represents a critical null pointer dereference issue within the Linux kernel's device mapper subsystem, specifically in the dm_suspend function. This flaw arises from a race condition between the suspension of device mapper devices and the completion of table loading operations, creating a scenario where kernel memory access violations can occur. The vulnerability manifests when the dm_suspend function attempts to process a device that has not yet completed its table loading phase, leading to a NULL pointer dereference at address 0x54 in the blk_mq_wait_quiesce_done function. This condition results in a kernel oops and potential system instability or crash, as demonstrated by the stack trace showing the execution path through blk_mq_quiesce_queue, dm_stop_queue, and ultimately __dm_suspend.
The technical root cause of this vulnerability lies in the improper handling of device mapper device states during concurrent operations. When a suspend operation is initiated while a table load is still in progress, the code path attempts to access q->tag_set which remains uninitialized or NULL at this stage. The race condition occurs because the suspend logic does not properly check whether a valid device mapper table (map) exists before proceeding with request-based suspension operations that depend on table-specific data structures. This issue is classified under CWE-476 as a null pointer dereference, and it aligns with ATT&CK technique T1068 which involves exploiting local privilege escalation through kernel vulnerabilities. The problematic sequence shows that during table load operations, the queue's mq_ops field is set before the tag_set field, but the suspend operation occurs in reverse order, creating the NULL pointer access when attempting to access q->tag_set.
The operational impact of this vulnerability is significant for systems utilizing device mapper functionality, particularly those employing dynamic volume management or storage virtualization. Attackers could potentially trigger this vulnerability through controlled race conditions involving dmsetup commands and concurrent device suspend operations, leading to system crashes or denial of service conditions. The vulnerability affects systems running Linux kernel versions that include the affected device mapper code, potentially compromising the stability of storage subsystems and applications relying on device mapper for volume management. While the immediate impact may be limited to system crashes rather than arbitrary code execution, the vulnerability creates a reliable method for causing system instability that could be exploited in denial of service attacks against critical infrastructure. The fix implemented addresses the issue by introducing a validation check to ensure that a valid table exists before executing table-dependent suspend logic, preventing the NULL pointer dereference while maintaining the integrity of the device mapper subsystem's suspension mechanism.
The mitigation strategy for this vulnerability involves applying the kernel patch that implements the check for valid table existence before proceeding with table-dependent suspension operations. This approach is consistent with defensive programming practices recommended by the Linux kernel security team and aligns with the principle of least privilege in system design. Organizations should prioritize patching affected systems, particularly those running device mapper-based storage configurations, as the vulnerability can be exploited to cause system instability. The fix is considered safe because when a map is NULL, no I/O can reach any target anyway, as I/O submitted in this state will fail early in the DM layer, making the skip of table-dependent suspend logic a non-risky operation. This vulnerability demonstrates the importance of proper synchronization mechanisms in kernel code and highlights the need for thorough testing of concurrent operations in complex subsystems like device mapper. System administrators should monitor for the patched kernel versions and ensure that all systems utilizing device mapper functionality are updated to prevent exploitation of this race condition.