CVE-2024-49980

What it actually does

The VRF driver removed an rcu_read_lock_bh() critical section around dev_queue_xmit_nit, violating the BH-disabled invariant required by __dev_queue_xmit and AF_PACKET socket locks, which produces an inconsistent lock state (IN-SOFTIRQ-W to SOFTIRQ-ON-W) and can trigger a deadlock when tpacket_rcv and vrf_finish_direct contend on the same spinlock from interrupt and process contexts.

Why it matters to the business

Linux systems using VRF interfaces may experience kernel lockups or crashes during routine network packet processing, leading to loss of connectivity, service outages, and the need for emergency reboots on affected servers and network appliances.

How an attack unfolds

An attacker or even legitimate traffic triggers the race by sending packets that traverse a VRF device while an AF_PACKET socket is bound; the missing BH protection allows the same spinlock to be acquired from both softirq and process contexts, causing the deadlock reported by lockdep.

How to fix it

Upgrade the Linux kernel to a version containing commit 718a752bd746b3f4dd62516bb437baf73d548415 or later; for Rocky Linux 8 install rpm package version 4.14.3-14.el8_4 or newer; rebuild and reboot with the patched kernel; disable VRF on unpatched systems if immediate upgrade is not possible.

How to confirm the fix worked

Boot the patched kernel and confirm the absence of the lockdep warning when exercising VRF + AF_PACKET workloads; verify the git commit or package version matches the fixed release; run lockdep-enabled stress tests that previously reproduced the warning.

Typical attack path

1. Configure a VRF interface on the target Linux system
2. Bind an AF_PACKET socket to capture or inject traffic on that VRF
3. Send or receive packets that cause vrf_l3_out to call dev_queue_xmit_nit
4. Trigger concurrent packet reception that acquires the AF_PACKET rlock from softirq context
5. Induce the lock-order inversion that produces the deadlock

How to detect it

Search kernel logs for the lockdep warning containing 'inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage' and 'rlock-AF_PACKET' together with stack traces referencing vrf_finish_direct and tpacket_rcv; inspect dmesg and journalctl for soft lockup or deadlock messages involving the vrf module.

What your security team should do

• Prioritize kernel upgrades on all systems that use VRF interfaces within the next maintenance window
• Add kernel version checks to vulnerability scanning and asset inventory
• Temporarily avoid VRF configurations on critical systems until patches are applied
• Monitor for related kernel oops or soft lockup reports in system logs