CVE-2026-46165

What it actually does

This is a local availability vulnerability in the Linux kernel Open vSwitch vport handling code. When an Open vSwitch tunnel port is deleted, reference release ordering can cause a self-deadlock during network device teardown. Specifically, the kernel can block in the RTNL/netdev cleanup path before the deferred RCU callback that would release the remaining reference is scheduled or completed. An attacker with local privileges sufficient to create and delete Open vSwitch tunnel ports can trigger the condition and hang affected networking/kernel paths, potentially causing severe service disruption or requiring a reboot.

Why it matters to the business

Systems using Open vSwitch for virtual switching, tunneling, container networking, virtualization, or software-defined networking may experience network outages or host instability if the flaw is triggered. The impact is primarily denial of service: workloads can lose connectivity, network management operations can hang, and recovery may require operational intervention or reboot. The CVSS score is moderate, EPSS is very low, it is not listed in CISA KEV, and there is no known public exploit maturity, so broad internet-scale exploitation is unlikely; however, shared compute, virtualization, and container platforms where local users or tenants can influence Open vSwitch configuration should treat it as higher priority.

How an attack unfolds

An attacker first needs local access to an affected Linux system and privileges that allow interaction with Open vSwitch or network device configuration, such as CAP_NET_ADMIN or administrative access to OVS management tooling. The attacker creates or targets an Open vSwitch tunnel vport, then triggers deletion of that tunnel port. Due to incorrect ordering of RCU cleanup and RTNL unlock operations, device teardown can wait for a reference that is not released in time, resulting in a self-deadlock. Once triggered, network device cleanup or Open vSwitch management operations may hang, causing loss of network availability for affected bridges, ports, or workloads. There are no named threat actors or ransomware campaigns currently associated with this vulnerability.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the Open vSwitch vport cleanup fix for this issue. No exact fixed package versions were provided in the input, so use vendor advisories, distribution errata, or stable kernel release notes to identify the corrected kernel build for each affected platform. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting CAP_NET_ADMIN and network namespace administration, preventing untrusted users or workloads from managing Open vSwitch bridges or tunnel ports, and tightly controlling access to ovs-vsctl, ovsdb-server, and OVS management APIs. On production systems, schedule maintenance for kernel upgrades because remediation generally requires booting into the fixed kernel.

How to confirm the fix worked

Confirm that affected systems are running a vendor kernel build that contains the Open vSwitch vport deadlock fix. Validate package state with distribution tooling such as rpm, dpkg, apt, yum, dnf, zypper, or the vendor appliance update mechanism, and confirm the active runtime kernel with uname -a after reboot. Review kernel changelogs or vendor advisories for references to the Open vSwitch vport tunnel-port release deadlock fix. Where safe in a non-production test environment, reproduce the operational workflow of creating and deleting OVS tunnel ports and verify that deletion completes normally, OVS commands return promptly, and kernel logs do not show netdev teardown waiting indefinitely.

Typical attack path

1. Gain local access to an affected Linux host running Open vSwitch.
2. Obtain or abuse privileges that allow network device or Open vSwitch port management, such as CAP_NET_ADMIN or equivalent administrative rights.
3. Create, modify, or identify an Open vSwitch tunnel port backed by the vulnerable vport cleanup path.
4. Delete the tunnel port or trigger device teardown.
5. Cause the kernel networking cleanup path to deadlock while waiting for references to drain.
6. Disrupt Open vSwitch networking, host network management operations, or dependent workloads until the deadlock is cleared, often requiring restart or reboot.

How to detect it

Review host telemetry for signs that the vulnerability was triggered rather than for remote compromise indicators. Useful sources include kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, Open vSwitch logs, audit logs for network administration commands, and process telemetry for ovs-vsctl or ip link operations that hang during tunnel deletion. Look for netdevice unregister waits, RTNL or RCU stalls, soft lockups, hung tasks, and stack traces involving Open vSwitch vport deletion, rtnl_unlock, netdev_run_todo, synchronize_net, or RCU callback handling. Correlate these events with administrative activity such as deletion of OVS tunnel ports, bridge changes, or privileged container/network namespace operations. Because this is a denial-of-service race/deadlock issue, exploitation may leave only operational artifacts: hung commands, blocked kernel threads, repeated OVS port deletion attempts, and network outage timestamps rather than malware files or external network indicators.

• unregister_netdevice: waiting for
• netdev_run_todo
• rtnl_unlock
• synchronize_net
• call_rcu
• ovs_vport
• vport
• openvswitch
• ovs-vswitchd
• ovs-vsctl del-port
• ovs-vsctl --if-exists del-port
• ip link delete
• INFO: task
• blocked for more than
• RCU stall
• soft lockup
• hung_task_timeout_secs
• /var/log/kern.log
• /var/log/messages
• /var/log/openvswitch/ovs-vswitchd.log
• /var/log/openvswitch/ovsdb-server.log

What your security team should do

• Inventory Linux systems using Open vSwitch, especially virtualization hosts, Kubernetes/container networking nodes, SDN gateways, and network appliances.
• Prioritize patching systems where local users, containers, automation, or tenants can influence network namespace, tunnel, or Open vSwitch configuration.
• Upgrade affected systems to a vendor kernel containing the fix and reboot into the corrected kernel.
• Restrict CAP_NET_ADMIN, privileged containers, and access to OVS management utilities to trusted administrators only.
• Monitor for repeated creation and deletion of Open vSwitch tunnel ports, hung ovs-vsctl commands, kernel soft lockups, and netdev unregister wait messages.
• Add operational runbooks for safely recovering affected hosts if OVS or kernel network teardown becomes stuck.
• Because EPSS is low and the vulnerability is not in KEV, prioritize based on OVS exposure and local privilege boundaries rather than internet exposure alone.