CVE-2025-21983 in Linux
Summary
by MITRE • 04/01/2025
In the Linux kernel, the following vulnerability has been resolved:
mm/slab/kvfree_rcu: Switch to WQ_MEM_RECLAIM wq
Currently kvfree_rcu() APIs use a system workqueue which is "system_unbound_wq" to driver RCU machinery to reclaim a memory.
Recently, it has been noted that the following kernel warning can be observed:
<snip> workqueue: WQ_MEM_RECLAIM nvme-wq:nvme_scan_work is flushing !WQ_MEM_RECLAIM events_unbound:kfree_rcu_work WARNING: CPU: 21 PID: 330 at kernel/workqueue.c:3719 check_flush_dependency+0x112/0x120 Modules linked in: intel_uncore_frequency(E) intel_uncore_frequency_common(E) skx_edac(E) ... CPU: 21 UID: 0 PID: 330 Comm: kworker/u144:6 Tainted: G E 6.13.2-0_g925d379822da #1 Hardware name: Wiwynn Twin Lakes MP/Twin Lakes Passive MP, BIOS YMM20 02/01/2023 Workqueue: nvme-wq nvme_scan_work RIP: 0010:check_flush_dependency+0x112/0x120 Code: 05 9a 40 14 02 01 48 81 c6 c0 00 00 00 48 8b 50 18 48 81 c7 c0 00 00 00 48 89 f9 48 ... RSP: 0018:ffffc90000df7bd8 EFLAGS: 00010082 RAX: 000000000000006a RBX: ffffffff81622390 RCX: 0000000000000027 RDX: 00000000fffeffff RSI: 000000000057ffa8 RDI: ffff88907f960c88 RBP: 0000000000000000 R08: ffffffff83068e50 R09: 000000000002fffd R10: 0000000000000004 R11: 0000000000000000 R12: ffff8881001a4400 R13: 0000000000000000 R14: ffff88907f420fb8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88907f940000(0000) knlGS:0000000000000000 CR2: 00007f60c3001000 CR3: 000000107d010005 CR4: 00000000007726f0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xa4/0x140 ? check_flush_dependency+0x112/0x120 ? report_bug+0xe1/0x140 ? check_flush_dependency+0x112/0x120 ? handle_bug+0x5e/0x90 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? timer_recalc_next_expiry+0x190/0x190 ? check_flush_dependency+0x112/0x120 ? check_flush_dependency+0x112/0x120 __flush_work.llvm.1643880146586177030+0x174/0x2c0 flush_rcu_work+0x28/0x30 kvfree_rcu_barrier+0x12f/0x160 kmem_cache_destroy+0x18/0x120 bioset_exit+0x10c/0x150 disk_release.llvm.6740012984264378178+0x61/0xd0 device_release+0x4f/0x90 kobject_put+0x95/0x180 nvme_put_ns+0x23/0xc0 nvme_remove_invalid_namespaces+0xb3/0xd0 nvme_scan_work+0x342/0x490 process_scheduled_works+0x1a2/0x370 worker_thread+0x2ff/0x390 ? pwq_release_workfn+0x1e0/0x1e0 kthread+0xb1/0xe0 ? __kthread_parkme+0x70/0x70 ret_from_fork+0x30/0x40 ? __kthread_parkme+0x70/0x70 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]---
<snip>
To address this switch to use of independent WQ_MEM_RECLAIM workqueue, so the rules are not violated from workqueue framework point of view.
Apart of that, since kvfree_rcu() does reclaim memory it is worth to go with WQ_MEM_RECLAIM type of wq because it is designed for this purpose.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 02/01/2026
The vulnerability described in CVE-2025-21983 relates to improper workqueue usage within the Linux kernel's memory management subsystem, specifically affecting the kvfree_rcu() API implementation. This issue manifests as a kernel warning indicating a violation of workqueue framework rules when the system attempts to flush work items between different workqueue types. The problem occurs when the kernel's RCU (Read-Copy-Update) memory reclamation mechanism attempts to process work items through a system workqueue that does not properly align with the memory reclamation requirements. The kernel warning trace demonstrates that a work item from the nvme-wq workqueue attempting to flush events is encountering conflicts with the system_unbound_wq workqueue that kvfree_rcu() was previously utilizing. This situation creates potential deadlocks and system instability during memory reclamation operations, particularly when dealing with device drivers such as NVMe subsystems that heavily utilize RCU mechanisms. The vulnerability is classified under CWE-691 as insufficient control flow management, specifically related to improper workqueue usage patterns that violate kernel subsystem constraints. From an operational perspective, this vulnerability impacts system reliability during memory reclamation phases, potentially causing system hangs or crashes when multiple subsystems attempt to coordinate memory management operations through conflicting workqueue mechanisms.
The technical flaw stems from the kvfree_rcu() API's reliance on the system_unbound_wq workqueue which lacks the appropriate memory reclamation characteristics required for proper RCU operation. The kernel's workqueue framework enforces strict rules about which workqueues can flush events from others to prevent deadlock conditions and ensure proper ordering. When kvfree_rcu() operations attempt to reclaim memory through a workqueue that does not have the WQ_MEM_RECLAIM flag set, it violates these fundamental framework constraints. The warning message specifically indicates that the kernel detected an attempt to flush !WQ_MEM_RECLAIM events through a WQ_MEM_RECLAIM workqueue, creating a dependency violation that can lead to system instability. This design flaw is particularly problematic in high-concurrency environments where multiple subsystems are simultaneously managing memory through RCU mechanisms. The improper workqueue classification affects not only the immediate memory reclamation operations but also the broader system's ability to maintain consistent memory management policies across different kernel subsystems. The kernel's check_flush_dependency function is explicitly designed to detect and prevent these types of violations, which explains why the system generates the warning message when this condition is encountered.
The operational impact of this vulnerability extends beyond simple performance degradation to potential system crashes and memory management failures during critical operations. When NVMe subsystems or other drivers that heavily rely on kvfree_rcu() functionality attempt to perform memory reclamation, they may trigger the kernel's warning mechanism, potentially leading to system hangs or the forced termination of memory management operations. The vulnerability is particularly concerning in enterprise environments where storage subsystems and memory-intensive applications are common, as these scenarios are more likely to trigger the problematic code paths. From a threat modeling perspective, this vulnerability could be exploited to cause denial of service conditions by forcing the kernel into memory reclamation paths that violate framework constraints, potentially leading to system instability. The issue affects the fundamental memory management capabilities of the kernel, which can cascade into broader system reliability problems. The ATT&CK framework would categorize this as a system resource exhaustion or denial of service attack vector, though it is more accurately classified as a kernel design flaw that can be triggered by normal system operations rather than malicious input.
The recommended mitigation involves switching the kvfree_rcu() implementation to utilize a dedicated WQ_MEM_RECLAIM workqueue instead of the system_unbound_wq. This change aligns the memory reclamation operations with the kernel's intended design patterns for handling memory pressure scenarios, where the workqueue type is explicitly designed to support memory reclamation activities. The fix ensures that when kvfree_rcu() operations attempt to reclaim memory, they do so through a workqueue that has the appropriate memory management characteristics and framework compliance. This approach prevents the dependency violations that currently occur and ensures proper coordination between different kernel subsystems during memory reclamation operations. The implementation should maintain backward compatibility while providing the necessary framework compliance to prevent the kernel warnings and potential system instability. Additionally, system administrators should monitor for the kernel warning messages during normal operation, as these can serve as early indicators of memory pressure conditions that might be exacerbated by this vulnerability. The solution directly addresses the root cause by ensuring that memory reclamation operations use workqueues that are specifically designed for this purpose, thereby eliminating the framework constraint violations that trigger the kernel's safety mechanisms.