CVE-2025-21761

What it actually does

Missing RCU protection in ovs_vport_cmd_fill_info() allows the function to be invoked without RTNL or RCU held, enabling a use-after-free on network device structures via dev_net_rcu().

Why it matters to the business

Local attackers can achieve kernel-level code execution and full system compromise on Linux hosts running Open vSwitch, risking data theft, persistence, and lateral movement; high prevalence in cloud and container environments increases exposure.

How an attack unfolds

An attacker with local access triggers ovs_vport_cmd_fill_info() under conditions where RCU protection is absent, races to free the underlying net device structure, then reuses the dangling pointer to execute arbitrary kernel code for privilege escalation, similar to patterns seen in related Linux kernel privilege-escalation campaigns.

How to fix it

Update the Linux kernel to the commit e85a25d1a9985645e796039e843d1de581d2de1e or later stable releases that apply RCU protection and dev_net_rcu() in ovs_vport_cmd_fill_info(). Rebuild and reboot affected systems; apply vendor kernel updates promptly given the local privilege-escalation impact.

How to confirm the fix worked

Verify the running kernel contains commit e85a25d1a9985645e796039e843d1de581d2de1e by checking /proc/version or kernel source; confirm ovs_vport_cmd_fill_info() uses RCU read-side critical sections and dev_net_rcu() via code review or binary diffing.

Typical attack path

1. Obtain local shell on target Linux system with Open vSwitch enabled
2. Invoke netlink commands that reach ovs_vport_cmd_fill_info() without holding required locks
3. Trigger concurrent operation that frees the referenced network device structure
4. Reuse freed memory to corrupt kernel data structures or redirect execution
5. Escalate to root and install persistence or move laterally

How to detect it

Review kernel audit logs and netlink traces for unexpected calls to ovs_vport commands; look for crash reports or oops involving openvswitch module and freed net_device structures; correlate with privilege-escalation attempts in related kernel CVEs.

What your security team should do

• Prioritize kernel updates on all systems exposing Open vSwitch netlink interfaces
• Restrict unprivileged local access and monitor for unusual netlink activity to ovs_vport
• Harden container hosts and cloud instances where Open vSwitch is common
• Track related kernel privilege-escalation CVEs for cumulative patching