CVE-2024-49980 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
vrf: revert "vrf: Remove unnecessary RCU-bh critical section"
This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.
dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following:
/* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh();
VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning:
================================ WARNING: inconsistent lock state 6.11.0 #1 Tainted: G W -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30
{IN-SOFTIRQ-W} state was registered at:
lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 packet_rcv+0xa33/0x1320 __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 __netif_receive_skb_list_core+0x2c9/0x890 netif_receive_skb_list_internal+0x610/0xcc0 [...]
other info that might help us debug this: Possible unsafe locking scenario:
CPU0 ---- lock(rlock-AF_PACKET); lock(rlock-AF_PACKET);
*** DEADLOCK ***
Call Trace: dump_stack_lvl+0x73/0xa0 mark_lock+0x102e/0x16b0 __lock_acquire+0x9ae/0x6170 lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 tpacket_rcv+0x863/0x3b30 dev_queue_xmit_nit+0x709/0xa40 vrf_finish_direct+0x26e/0x340 [vrf]
vrf_l3_out+0x5f4/0xe80 [vrf]
__ip_local_out+0x51e/0x7a0 [...]
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/21/2026
The vulnerability CVE-2024-49980 addresses a critical issue within the Linux kernel's Virtual Routing and Forwarding (VRF) subsystem, specifically concerning improper handling of bottom-half (BH) disabled contexts during packet transmission. This flaw stems from the removal of an essential RCU (Read-Copy-Update) critical section in commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853, which was subsequently reverted to resolve inconsistencies in kernel locking behavior. The VRF module, designed to enable multiple routing tables within a single network namespace, requires strict adherence to kernel locking invariants to maintain system stability and prevent race conditions.
The core technical issue arises when the dev_queue_xmit_nit function is invoked, which expects soft interrupts to be disabled as part of its operational contract. The __dev_queue_xmit function properly disables soft interrupts through rcu_read_lock_bh(), ensuring that RCU grace periods are not interrupted during critical sections. However, the removal of this protection in the referenced commit caused a violation of the expected locking semantics, triggering lockdep warnings that indicate inconsistent lock state. The warning shows a transition from {IN-SOFTIRQ-W} to {SOFTIRQ-ON-W} usage, highlighting a scenario where locks are acquired while soft interrupts are enabled, which violates kernel locking discipline.
This inconsistency manifests as a potential deadlock condition that can severely impact network functionality and system stability. When the VRF subsystem processes packets through vrf_finish_direct and vrf_l3_out functions, the improper locking context causes the kernel's lock validator to detect an unsafe locking scenario. The call trace demonstrates how the issue propagates from packet reception through tpacket_rcv, eventually reaching dev_queue_xmit_nit and the VRF-specific functions, creating a chain of function calls that expose the underlying race condition. This vulnerability directly relates to CWE-691, which covers insufficient control flow management, and aligns with ATT&CK technique T1547.001 for privilege escalation through kernel exploitation.
The operational impact of this vulnerability extends beyond simple network disruption, as it can lead to system crashes, packet loss, and potential denial of service conditions in environments heavily reliant on VRF functionality. Systems using multiple routing tables for network segmentation or virtualized network environments are particularly susceptible to this issue. Mitigation strategies should include applying the kernel patch that reverts the problematic commit, ensuring all network operations maintain proper soft interrupt handling, and implementing monitoring for lockdep warnings. Organizations should also consider updating their kernel versions to include the fix, as this vulnerability affects the core networking subsystem and could potentially be exploited to gain unauthorized access to network resources or disrupt critical services. The fix ensures that VRF operations correctly maintain the expected BH disabled context, thereby preserving kernel locking integrity and preventing the deadlock scenarios that could compromise system stability.