CVE-2024-47696 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency
In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs"), the function flush_workqueue is invoked to flush the work queue iwcm_wq.
But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.
Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock.
The call trace is as below:
[ 125.350876][ T1430] Call Trace:
[ 125.356281][ T1430]
[ 125.361285][ T1430] ? __warn (kernel/panic.c:693)
[ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)
[ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)
[ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
[ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)
[ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)
[ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)
[ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm
[ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)
[ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
[ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)
[ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm
[ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma
[ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma
[ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)
[ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)
[ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)
[ 125.531837][ T1430] kthread (kernel/kthread.c:389)
[ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
[ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)
[ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
[ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)
[ 125.566487][ T1430]
[ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/19/2026
The vulnerability described in CVE-2024-47696 relates to a critical issue within the Linux kernel's RDMA (Remote Direct Memory Access) implementation, specifically within the iwcm (InfiniBand Work Queue Connection Manager) subsystem. This flaw manifests as a potential deadlock condition that arises from improper handling of workqueue flushing operations, particularly when dealing with the destruction of connection management identifiers. The root cause stems from a lack of proper memory reclamation flags during workqueue initialization, which creates a dangerous dependency that can prevent forward progress in system operations.
The technical flaw occurs when the function flush_workqueue is invoked on the iwcm_wq workqueue, which was initialized using alloc_ordered_workqueue without the WQ_MEM_RECLAIM flag. This configuration creates a scenario where the kernel's memory management subsystem can become deadlocked if the current process attempts to flush the workqueue while the system is in a memory reclamation state. The kernel's workqueue subsystem includes built-in checks to prevent such scenarios, as demonstrated by the check_flush_dependency function in kernel/workqueue.c, which explicitly warns against flushing workqueues that lack the WQ_MEM_RECLAIM flag under memory pressure conditions. The call trace reveals a complex chain of function calls starting from the destruction of connection manager IDs through nvme_rdma operations, ultimately leading to the problematic flush operation.
The operational impact of this vulnerability is significant, particularly in high-performance computing environments that rely heavily on RDMA technologies for network communication. Systems using InfiniBand or RDMA over Converged Ethernet (RoCE) interfaces may experience complete system hangs or kernel oops conditions when attempting to tear down RDMA connections or reset RDMA controllers. This vulnerability affects not only the stability of individual systems but can also lead to broader service disruptions in data center environments where RDMA is extensively used for storage and network I/O operations. The deadlock condition can cause the kernel to become unresponsive, requiring manual intervention or system reboot to restore normal operations, which is particularly problematic in production environments where uptime is critical.
Mitigation strategies for this vulnerability involve applying the kernel patch that properly configures the iwcm_wq workqueue with the WQ_MEM_RECLAIM flag during initialization. This ensures that the workqueue can safely handle memory reclamation scenarios without causing deadlocks. System administrators should prioritize updating their kernel versions to include the fix from commit aee2424246f9, which addresses the core issue by ensuring proper workqueue configuration. Additionally, monitoring systems should be implemented to detect potential deadlock conditions, and administrators should consider implementing memory pressure handling mechanisms that can gracefully manage workqueue operations during high-memory usage periods. From a security perspective, this vulnerability aligns with CWE-362, which deals with race conditions, and maps to ATT&CK technique T1490, which involves denial of service through resource exhaustion, as the deadlock condition effectively prevents normal system operations and can be exploited to cause system unavailability.
The fix for this vulnerability demonstrates the importance of proper kernel workqueue management and memory reclamation handling in high-performance subsystems. The solution requires careful consideration of the interaction between different kernel subsystems and proper flag configuration to prevent dangerous dependencies. This issue highlights the complexity of kernel-level programming where seemingly minor configuration changes can have cascading effects on system stability and performance. Organizations using RDMA technologies should conduct thorough testing of kernel updates to ensure that the fix does not introduce any regressions in their RDMA-based applications or services.