CVE-2025-21791

What it actually does

Missing RCU read-side protection in l3mdev_l3_out() allows a use-after-free when the function is invoked from the IPv4 output path (raw_sendmsg o ip_push_pending_frames o ip_send_skb o ip_local_out o __ip_local_out) without an RCU read lock held, permitting concurrent VRF device teardown to free data structures still in use.

Why it matters to the business

Linux-based network appliances, servers, and embedded devices face kernel instability or potential local privilege escalation, which can interrupt network services and require emergency patching across large fleets; the issue has been public for over 600 days with no ransomware usage recorded.

How an attack unfolds

An attacker with local access or the ability to trigger packet transmission on a system using VRF devices sends or causes traffic that walks the unprotected l3mdev_l3_out() call chain; a concurrent VRF deletion frees the l3mdev structure while it is still referenced, enabling a classic use-after-free that can be turned into arbitrary read/write or code execution by kernel exploit techniques observed in other Linux kernel campaigns.

How to fix it

Update the Linux kernel to a version containing commit 6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e (or the equivalent stable backport) which wraps l3mdev_l3_out() with rcu_read_lock()/rcu_read_unlock(); rebuild and reboot all affected systems; where immediate patching is impossible, restrict unprivileged local access and avoid VRF configurations until the fix is applied.

How to confirm the fix worked

Confirm the running kernel contains commit 6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e via 'uname -r' and kernel source inspection or package changelog; exercise network paths that invoke l3mdev_l3_out() under concurrent VRF add/delete while monitoring for use-after-free warnings in dmesg or KASAN reports.

Typical attack path

1. Obtain local execution or network-adjacent position on a VRF-enabled Linux host
2. Trigger packet transmission through the IPv4 output path that reaches l3mdev_l3_out() without RCU held
3. Race with VRF device deletion to free the structure while it is still referenced
4. Leverage the resulting dangling pointer for kernel memory corruption or information leak
5. Escalate to root or persist within the kernel

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for use-after-free or RCU warnings referencing l3mdev_l3_out or vrf; inspect network packet captures and system-call traces for unusual raw socket or VRF device manipulation around the time of any kernel oops; correlate with process creation events showing privilege-escalation tools commonly used in Linux kernel exploits.

What your security team should do

• Prioritize kernel updates on all internet-facing and multi-tenant Linux systems within the next maintenance window
• Inventory VRF usage across the environment and apply the fix first to those hosts
• Enable kernel hardening features such as KASAN or lockdown mode where performance permits until patches are deployed
• Monitor vendor advisories for backported fixes in distribution kernels