CVE-2026-46165: Linux Kernel Privilege Escalation Flaw

CVE-2026-46165 Overview

CVE-2026-46165 is a self-deadlock vulnerability in the Linux kernel's Open vSwitch (openvswitch) subsystem. The flaw exists in the virtual port (vport) release path for tunnel ports. When a tunnel device is deleted, rtnl_unlock() invokes netdev_run_todo() and blocks until all references are released. Because the call_rcu() that drops the final reference is scheduled after rtnl_unlock(), the callback never runs, and the vport is never freed. The system thread holding the Routing Netlink (RTNL) lock waits indefinitely for itself.

Critical Impact

Local users with CAP_NET_ADMIN who delete tunnel ports trigger a self-deadlock, hanging the kernel thread and degrading networking subsystem availability.

Affected Products

• Linux kernel branches containing the affected openvswitch vport release logic
• Distributions shipping vulnerable kernels with Open vSwitch enabled
• Systems using OVS tunnel ports (GRE, VXLAN, Geneve, etc.)

Discovery Timeline

• 2026-05-28 - CVE-2026-46165 published to the National Vulnerability Database (NVD)
• 2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-46165

Vulnerability Analysis

The Open vSwitch kernel module manages virtual ports concurrently and protects them using Read-Copy-Update (RCU). Releasing a netdev reference via netdev_put() must occur after an RCU grace period to ensure no concurrent readers still hold the pointer. The original implementation issued rtnl_delete_link() under the RTNL lock and then attempted to drop the netdev reference.

The deadlock arises because rtnl_unlock() calls netdev_run_todo(), which synchronously waits for outstanding device references to be released. The scheduled RCU callback responsible for calling netdev_put() was queued only after rtnl_unlock() returned. The thread therefore blocks inside rtnl_unlock() waiting for a reference release that can never be scheduled, producing a permanent hang.

Root Cause

The root cause is incorrect ordering of operations between RTNL-protected device teardown and RCU-deferred reference dropping [CWE-833 Deadlock]. The call_rcu() invocation needed to occur before rtnl_unlock() so that the grace period triggered by synchronize_net() inside netdev_run_todo() would execute the pending callback while RTNL is no longer held.

Attack Vector

Exploitation requires local privileges sufficient to manipulate Open vSwitch tunnel ports, typically CAP_NET_ADMIN. An administrator removing a tunnel vport during normal OVS operations can trigger the deadlock. The result is a hung task in the networking subsystem rather than memory corruption or privilege escalation, so the impact is limited to denial of service on the affected host.

The fix relocates the call_rcu() scheduling to occur before rtnl_unlock(). The RCU callback then executes when netdev_run_todo() invokes synchronize_net(), releasing the reference while RTNL is already unlocked. See the Linux Kernel Commit 366c48 and Linux Kernel Commit 3df75f for the upstream patches.

Detection Methods for CVE-2026-46165

Indicators of Compromise

• Hung task warnings in dmesg referencing rtnl_unlock, netdev_run_todo, or openvswitch symbols
• Processes blocked in D (uninterruptible sleep) state when running ovs-vsctl del-port against tunnel interfaces
• RTNL lock contention causing subsequent ip link or ovs-vsctl commands to hang indefinitely

Detection Strategies

• Monitor kernel logs for hung_task_timeout_secs warnings tied to RTNL or openvswitch stack traces
• Audit running kernel versions across fleets and flag hosts running Open vSwitch on unpatched kernels
• Track success and latency of OVS tunnel port deletion operations in orchestration platforms

Monitoring Recommendations

• Enable CONFIG_DETECT_HUNG_TASK and forward kernel ring buffer events to centralized logging
• Alert on stalled ovs-vswitchd operations and increased Netlink request latency
• Correlate node reboots or kernel hangs on hosts running OVS with recent tunnel port configuration changes

How to Mitigate CVE-2026-46165

Immediate Actions Required

• Identify hosts running Open vSwitch with tunnel ports configured (GRE, VXLAN, Geneve)
• Apply the upstream kernel patches or update to a distribution kernel that incorporates the fix
• Avoid frequent teardown of tunnel ports on unpatched kernels until the patch is deployed

Patch Information

The vulnerability is resolved by reordering the call_rcu() invocation to precede rtnl_unlock() in the openvswitch vport release path. Applicable commits include Linux Kernel Commit 366c48, Linux Kernel Commit 3df75f, Linux Kernel Commit 6522d5, Linux Kernel Commit aa6991, and Linux Kernel Commit c74143. Coordinate with your distribution vendor to obtain a backported kernel package.

Workarounds

• Restrict CAP_NET_ADMIN to trusted administrators and automation accounts only
• Schedule tunnel port deletions during maintenance windows where a node reboot is acceptable if a hang occurs
• Where possible, replace tunnel ports via configuration reload rather than deleting and recreating them

# Verify the running kernel version and Open vSwitch usage
uname -r
lsmod | grep openvswitch
ip -d link show type vxlan
ip -d link show type gre