CVE-2025-40134

In the Linux kernel, the following vulnerability has been resolved:

dm: fix NULL pointer dereference in _dmsuspend()

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:blkmqwaitquiescedone+0x0/0x50 Call Trace: <TASK> blkmqquiescequeue+0x2c/0x50 dmstopqueue+0xd/0x20 _dmsuspend+0x130/0x330 dmsuspend+0x11a/0x180 devsuspend+0x27e/0x560 ctlioctl+0x4cf/0x850 dmctlioctl+0xd/0x20 vfsioctl+0x1d/0x50 _sesysioctl+0x9b/0xc0 _x64sysioctl+0x19/0x30 x64syscall+0x2c4a/0x4620 dosyscall_64+0x9e/0x1b0

The issue can be triggered as below:

T1 T2 dmsuspend tableload _dmsuspend dmsetupmdqueue dmmqinitrequestqueue blkmqinitallocatedqueue => q->mqops = set->ops; (1) dmstopqueue / dmwaitforcompletion => q->tagset 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.