CVE-2026-52925

What it actually does

This is a Linux kernel race condition in VRF port removal. RCU readers can observe a network device that was previously marked as a VRF L3 slave while its master device has already changed to a non-VRF device, such as a bridge. Kernel paths that assume the master has l3mdev operations may then dereference a NULL function table, causing a kernel NULL pointer dereference in l3mdev_fib_table_rcu during networking operations such as bind(). The most likely impact is local denial of service through a kernel oops or panic, depending on kernel panic-on-oops configuration. Exploitation generally requires the ability to alter network device topology, typically CAP_NET_ADMIN or equivalent privileges in a network namespace.

Why it matters to the business

Systems using Linux VRF networking can become unstable or crash when VRF ports are removed or reassigned under race conditions. The primary operational consequence is loss of availability for workloads, network appliances, routing hosts, container platforms, or multi-tenant systems that depend on Linux networking namespaces and VRF isolation. The public exploitation signal is currently low: EPSS is 0.00114, it is not listed in CISA KEV, no ransomware association is indicated, and no mature public exploit is reported. However, organizations that delegate network administration capabilities to containers, automation, or less-trusted users should treat this with higher priority because the required trigger may be reachable from those contexts.

How an attack unfolds

An attacker first needs local access to a system or container context with sufficient network administration capability to create, delete, or reassign network devices involving VRF interfaces. They then create a timing race in which one execution path removes a port from a VRF or changes its upper master device, while another path performs networking operations that cause the kernel to query the device's L3 master state, such as binding a socket. In the vulnerable window, an RCU reader may still treat the device as a VRF slave but retrieve a different master device that does not provide l3mdev operations. The subsequent dereference of the missing l3mdev operations table triggers a kernel NULL pointer dereference. If the system is configured to panic on oops, the host may crash immediately; otherwise the affected task may fail and the kernel may remain in a degraded or unstable state. There are no currently reported named threat actors or known ransomware campaigns exploiting this issue.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the VRF RCU synchronization fix for port removal. Because no exact fixed package versions were provided, use vendor advisories and changelogs to identify the first fixed kernel for each supported distribution, appliance, or managed kernel stream. Reboot into the fixed kernel after installation; merely installing the package is insufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by restricting CAP_NET_ADMIN, disabling unprivileged user namespaces where operationally feasible, preventing untrusted containers from managing network devices, limiting VRF topology changes to trusted automation, and avoiding rapid reassignment of interfaces between VRF and non-VRF master devices on vulnerable kernels. Ensure crash behavior is understood: disabling panic-on-oops may reduce full-host outage risk but does not remediate the vulnerability.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a vendor build containing the fix. Validate with uname -a, package manager metadata, vendor security advisories, and kernel changelogs referencing a VRF/l3mdev RCU synchronization fix for removing a port from a VRF. Check whether the system uses VRF networking with commands such as ip -d link show type vrf and whether less-trusted workloads have CAP_NET_ADMIN. Review whether the kernel configuration and distribution backports include the relevant net/vrf and net/l3mdev changes; distribution kernels may be fixed without changing to an upstream mainline version number. After patching and rebooting, monitor dmesg and kernel logs for recurrence of NULL pointer dereferences involving l3mdev_fib_table_rcu, netdev_master_upper_dev_get_rcu, or VRF port removal.

Typical attack path

1. Gain local code execution or shell access on a Linux system, container, or network namespace with CAP_NET_ADMIN or equivalent network-device management privileges.
2. Create or identify VRF devices and ports, or a topology where a device can be moved between a VRF and another master device such as a bridge.
3. Repeatedly remove a port from the VRF or reassign its upper master device while concurrently triggering socket or routing operations that query L3 master device state.
4. Win the race where an RCU reader sees the device as a VRF slave but obtains a non-VRF master device without l3mdev operations.
5. Trigger a kernel NULL pointer dereference in the l3mdev path, causing a kernel oops or host panic depending on system configuration.

How to detect it

To determine whether this was already triggered, review kernel logs, persistent journal entries, crash dumps, and monitoring alerts for kernel NULL pointer dereferences in VRF or l3mdev code paths. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore repositories, system watchdog logs, and hypervisor or cloud instance reset events. Look for crashes or oops events around the same time as network interface changes, VRF port removals, bridge attachment changes, container network setup/teardown, or commands such as ip link set ... nomaster. Correlate kernel errors with audit logs or shell history showing CAP_NET_ADMIN activity, netlink operations, container lifecycle events, CNI plugin activity, or automation that moved interfaces between VRF and non-VRF masters. Because this issue produces a kernel fault rather than a distinctive remote payload, detection relies mainly on crash artifacts and local network-configuration activity preceding the fault.

• BUG: kernel NULL pointer dereference, address: 0000000000000000
• RIP: 0010:l3mdev_fib_table_rcu
• l3mdev_fib_table_by_index
• __inet_bind
• inet_bind_sk
• __sys_bind
• netdev_master_upper_dev_get_rcu
• netif_is_l3_slave
• IFF_L3MDEV_SLAVE
• kernel NULL pointer dereference
• Call Trace:
• ip link set * nomaster
• ip link add * type vrf
• ip link set * master *
• /var/crash
• /proc/vmcore

What your security team should do

• Prioritize patching hosts that use Linux VRF, container networking, routing, virtual networking, or delegated network administration capabilities.
• Inventory systems where containers, orchestration components, CI jobs, or users have CAP_NET_ADMIN or permission to create, delete, or move network interfaces.
• Apply vendor-fixed kernels and reboot affected systems into the fixed version; verify the active kernel after reboot.
• Temporarily restrict untrusted access to network namespaces and network device management on systems that cannot be patched promptly.
• Add monitoring for kernel oops, panic, and NULL pointer dereference events involving l3mdev or VRF functions.
• Review container runtime and Kubernetes security policies to prevent unnecessary CAP_NET_ADMIN grants.
• For high-availability network hosts, schedule patching with failover planning because the vulnerability can produce host-level availability impact.
• Track distribution advisories because fixed versions may be delivered as backports rather than obvious upstream version bumps.