CVE-2024-40980 in Linux
Summary
by MITRE • 07/12/2024
In the Linux kernel, the following vulnerability has been resolved:
drop_monitor: replace spin_lock by raw_spin_lock
trace_drop_common() is called with preemption disabled, and it acquires a spin_lock. This is problematic for RT kernels because spin_locks are sleeping locks in this configuration, which causes the following splat:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47 preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 2 5 locks held by rcuc/47/449: #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210
#1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130
#2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210
#3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70
#4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290
irq event stamp: 139909 hardirqs last enabled at (139908): [] _raw_spin_unlock_irqrestore+0x63/0x80
hardirqs last disabled at (139909): [] trace_drop_common.constprop.0+0x26d/0x290
softirqs last enabled at (139892): [] __local_bh_enable_ip+0x103/0x170
softirqs last disabled at (139898): [] rcu_cpu_kthread+0x93/0x1f0
Preemption disabled at: [] rt_mutex_slowunlock+0xab/0x2e0
CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7 Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022 Call Trace: dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 __might_resched+0x21e/0x2f0 rt_spin_lock+0x5e/0x130 ? trace_drop_common.constprop.0+0xb5/0x290 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_drop_common.constprop.0+0xb5/0x290 ? preempt_count_sub+0x1c/0xd0 ? _raw_spin_unlock_irqrestore+0x4a/0x80 ? __pfx_trace_drop_common.constprop.0+0x10/0x10 ? rt_mutex_slowunlock+0x26a/0x2e0 ? skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_rt_mutex_slowunlock+0x10/0x10 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_kfree_skb_hit+0x15/0x20 trace_kfree_skb+0xe9/0x150 kfree_skb_reason+0x7b/0x110 skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10 ? mark_lock.part.0+0x8a/0x520 ...
trace_drop_common() also disables interrupts, but this is a minor issue because we could easily replace it with a local_lock.
Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic context.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/21/2026
The vulnerability described in CVE-2024-40980 resides within the Linux kernel's drop_monitor subsystem, specifically in the trace_drop_common() function. This issue manifests as a critical concurrency problem that affects real-time (RT) kernel configurations. The function is invoked with preemption disabled, which creates a dangerous scenario where standard spin_lock operations attempt to sleep, violating kernel atomicity constraints. The kernel's locking mechanism in RT configurations treats spin_locks as sleeping locks, fundamentally incompatible with contexts where preemption is disabled. This mismatch leads to kernel oops and system instability, as evidenced by the splat showing the BUG message indicating that a sleeping function was called from an invalid context. The problem occurs when the rcuc/47 kernel thread attempts to acquire a spin_lock while in an atomic context, where the kernel expects no blocking operations. The stack trace reveals that the issue originates from rt_spin_lock attempting to acquire a lock that is already held by the same thread in a nested RCU context, creating a deadlock scenario. The kernel's RCU (Read-Copy-Update) subsystem is involved in the lock chain, with multiple locks held simultaneously, including softirq_ctrl.lock and rcu_read_lock, indicating a complex interaction between different kernel subsystems. The lock hierarchy violation occurs when trace_drop_common attempts to acquire the data->lock while already holding RCU locks, resulting in a nested locking scenario that the RT kernel cannot handle properly. This vulnerability is particularly severe in real-time environments where deterministic behavior and lock-free operations are essential for maintaining system responsiveness.
The technical root cause of this vulnerability lies in the inappropriate use of spin_lock within a context where preemption is disabled, specifically within the trace_drop_common() function that handles packet drop monitoring. The function disables interrupts and operates in atomic context, but attempts to acquire a spin_lock that, in RT kernel configurations, transforms into a sleeping lock mechanism. This design flaw stems from the fundamental difference between standard kernel locking and RT kernel locking behaviors, where spin_locks in RT contexts must not sleep to prevent system hangs. The kernel's locking infrastructure in real-time configurations requires the use of raw_spin_lock instead of spin_lock to ensure that no blocking operations occur within atomic contexts. The problem is exacerbated by the fact that the function also disables interrupts, creating a dual constraint environment where both preemption and interrupt handling are disabled, making any lock acquisition that might sleep fatal. The issue is further complicated by the nested RCU lock acquisition, where multiple locking primitives are involved in the call stack, making the lock ordering and context management extremely complex. This type of vulnerability is classified under CWE-664, which deals with improper control of a resource through multiple accesses, and specifically relates to improper locking mechanisms in concurrent programming. The vulnerability demonstrates a classic case of context mismatch where locking primitives are not properly adapted to the execution environment, leading to system crashes and potential denial of service conditions.
The operational impact of CVE-2024-40980 is significant, particularly for systems running real-time Linux kernels where predictable performance and deterministic behavior are critical. Systems utilizing the affected kernel version may experience kernel panics, system crashes, and complete system hangs when packet drops occur in monitored network interfaces. The vulnerability affects network monitoring and packet processing functionalities, potentially leading to loss of network connectivity or complete system failure. In production environments where real-time performance is essential, such as industrial control systems, telecommunications infrastructure, or automotive applications, this vulnerability could result in catastrophic failures. The issue impacts not just the immediate kernel subsystem but can cascade into broader system stability problems, as the kernel thread rcuc/47 becomes blocked and unable to continue its normal operations. Network packet drop monitoring, which is crucial for performance analysis and debugging, becomes unreliable and potentially dangerous. The vulnerability affects systems running kernel versions that include the drop_monitor subsystem, particularly those configured with real-time kernel patches. The impact extends beyond simple system crashes to include potential data loss, service interruptions, and security implications if the system becomes unresponsive. Organizations using real-time Linux configurations for mission-critical applications should consider immediate mitigation strategies to avoid potential operational disruptions.
The recommended mitigation for CVE-2024-40980 involves replacing the spin_lock with raw_spin_lock in the trace_drop_common() function to ensure compatibility with real-time kernel configurations. This change aligns with the kernel's design principles for atomic contexts, where raw_spin_lock provides the necessary locking behavior without the risk of sleeping operations. The fix directly addresses the root cause by ensuring that no blocking operations occur within the atomic context where preemption is disabled. System administrators should update to kernel versions that include this fix, typically those incorporating the patch that modifies the locking mechanism in the drop_monitor subsystem. Organizations running real-time Linux configurations should prioritize this update to prevent potential system crashes and maintain operational stability. The mitigation strategy also includes monitoring for any related kernel warnings or errors that might indicate improper locking usage in other subsystems. Additionally, system administrators should verify that their network monitoring tools and packet drop analysis mechanisms are functioning correctly after applying the patch. The fix demonstrates the importance of proper locking mechanism selection in kernel development, where the choice between spin_lock and raw_spin_lock can determine system stability in real-time environments. This vulnerability highlights the need for careful consideration of execution context when implementing kernel locking mechanisms and the critical importance of testing in real-time configurations to prevent such issues. The solution aligns with the ATT&CK framework's defense evasion techniques, as proper kernel locking prevents system instability that could otherwise be exploited to disrupt system operations. The change represents a straightforward but critical fix that ensures kernel subsystems maintain their intended behavior across different kernel configurations while preserving system reliability.