Race Condition Affecting kernel-64k-modules-partner package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS9-KERNEL64KMODULESPARTNER-13978961
- published14 Nov 2025
- disclosed12 Nov 2025
Introduced: 12 Nov 2025
NewCVE-2025-40134 (opens in a new tab)How to fix?
There is no fixed version for Centos:9 kernel-64k-modules-partner.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-64k-modules-partner package and not the kernel-64k-modules-partner package as distributed by Centos.
See How to fix? for Centos:9 relevant fixed versions and status.
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.
References
- https://access.redhat.com/security/cve/CVE-2025-40134
- https://git.kernel.org/stable/c/19ca4528666990be376ac3eb6fe667b03db5324d
- https://git.kernel.org/stable/c/30f95b7eda5966b81cb221bd569c0f095a068cf6
- https://git.kernel.org/stable/c/331c2dd8ca8bad1a3ac10cce847ffb76158eece4
- https://git.kernel.org/stable/c/846cafc4725ca727d94f9c4b5f789c1a7c8fb6fe
- https://git.kernel.org/stable/c/8d33a030c566e1f105cd5bf27f37940b6367f3be
- https://git.kernel.org/stable/c/9dc43ea6a20ff83fe9a5fe4be47ae0fbf2409b98
- https://git.kernel.org/stable/c/a0e54bd8d7ea79127fe9920df3ae36f85e79ac7c
- https://git.kernel.org/stable/c/a802901b75e13cc306f1b7ab0f062135c8034e9e