SEC.co
Emergency
MEDIUM 5.5

CVE-2026-46165

A self-deadlock vulnerability exists in the Linux kernel's Open vSwitch module when tunnel ports are released. The issue occurs because the code attempts to clean up network device references while holding locks that prevent the cleanup from completing, causing the system to hang during tunnel port deletion. This is a local denial-of-service condition that affects systems running vulnerable kernel versions with Open vSwitch configured.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.5 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
CWE-667
Affected products
6 configuration(s)
Published / Modified
2026-05-28 / 2026-06-17

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: openvswitch: vport: fix self-deadlock on release of tunnel ports vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. So, either in an RCU call or after the synchronize_net(). The rtnl_delete_link() must happen under RTNL and so can't be executed in RCU context. Calling synchronize_net() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdev_put() in RCU call is the right solution here. However, when the device is deleted, rtnl_unlock() will call netdev_run_todo() and block until all the references are gone. In the current code this means that we never reach the call_rcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal. Fix that by moving the rcu_call() before the rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from the rtnl_unlock()->netdev_run_todo() while the RTNL itself is already released.

6 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability stems from incorrect lock ordering and timing in the OVS vport cleanup path. When a tunnel port is deleted, the kernel must release references to the underlying network device (netdev_put) after an RCU grace period completes. The original code schedules this cleanup via call_rcu() after calling rtnl_unlock(), but rtnl_unlock() internally calls netdev_run_todo() which blocks until all device references are released. This creates a circular wait: the RCU callback never executes because rtnl_unlock() blocks, waiting for the very reference that the RCU callback would release. The fix reorders the call_rcu() to execute before rtnl_unlock(), allowing the RCU callback to run during the synchronize_net() call within netdev_run_todo(), breaking the deadlock cycle. The vulnerability is classified as CWE-667 (improper locking).

Business impact

Affected systems experience availability disruption when tunnel ports in Open vSwitch deployments are removed or recreated. In cloud environments, container platforms, or network virtualization deployments relying on OVS, this could cause kernel hangs, requiring node reboots and interrupting workload execution. The impact is localized to the host where the condition occurs, but widespread deployment of affected kernels in clustered environments could cause cascading availability issues.

Affected systems

The vulnerability affects Linux kernel systems with Open vSwitch (OVS) tunnel port functionality enabled. This includes cloud platforms using OVS for software-defined networking, container orchestration systems, network function virtualization deployments, and Linux distributions where kernel vulnerability fixes have not been applied. The condition requires local access and OVS tunnel port configuration to trigger.

Exploitability

Exploitability is low-to-moderate. The vulnerability requires local access and the ability to trigger tunnel port deletion or modification, typically available to unprivileged local users in multi-tenant or shared-access scenarios. No remote exploitation is possible. The condition is highly reliable to trigger once preconditions are met, as any tunnel port removal will reliably hang the kernel. However, the attack surface is limited to systems with OVS tunnel functionality actively configured.

Remediation

Apply kernel updates containing the OVS vport deadlock fix. Verify the patch version against your Linux distribution's security advisory. The fix relocates the call_rcu() invocation before rtnl_unlock() to ensure RCU callbacks execute during the netdev_run_todo() blocking period. Distributions have or will backport this fix to all affected stable branches. As an interim mitigation, limit local user access to systems with OVS tunnel ports, though this does not eliminate the vulnerability.

Patch guidance

Obtain and deploy the kernel update from your Linux distribution's security repository. The fix is integrated into mainline Linux and all stable branches. Verify the specific patch version against your distribution's advisory (e.g., RHEL, Ubuntu, Debian, SUSE), as backport version numbers vary. Testing should confirm tunnel port add/remove operations complete without kernel hangs. Reboot systems to apply kernel updates.

Detection guidance

Monitor for kernel hang or soft lockup warnings in system logs, particularly those referencing OVS, netdev cleanup, or RCU callbacks. Detection tools: check kernel logs for 'BUG: soft lockup' or 'RCU stall' messages during OVS port operations; use systemtap or eBPF probes to trace call_rcu() and rtnl_unlock() ordering in the vport deletion path; correlate kernel panics or reboots with tunnel port configuration changes. Affected systems will show reproducible hangs when tunnel ports are deleted.

Why prioritize this

This vulnerability merits prompt patching due to high availability impact in virtualized and containerized environments where OVS is prevalent. The reliable, reproducible nature of the hang makes it a practical denial-of-service vector. However, the requirement for local access and OVS configuration limits urgency compared to remote code execution risks. Organizations with OVS deployments should prioritize patching; others may defer based on risk profile. CVSS 5.5 (MEDIUM) reflects the local, availability-only impact.

Risk score, explained

CVSS 3.1 score of 5.5 (MEDIUM) reflects: local attack vector (AV:L), low complexity (AC:L), low privilege requirement (PR:L), no user interaction (UI:N), unchanged scope (S:U), no confidentiality or integrity impact (C:N/I:N), but high availability impact (A:H). The score appropriately weights the denial-of-service severity against the local-only attack requirement and absence of data breach risk.

Frequently asked questions

Does this vulnerability affect systems without Open vSwitch installed?

No. The vulnerability is specific to the OVS vport subsystem in the Linux kernel. Systems not running OVS are unaffected, regardless of kernel version.

Can this be exploited remotely?

No. The vulnerability requires local access to trigger tunnel port operations. Remote attackers cannot exploit it without prior system compromise.

What happens when the deadlock is triggered?

The kernel hangs during tunnel port removal. The system becomes unresponsive and typically requires a hard reboot to recover. No data corruption occurs, but availability is lost until the reboot completes.

Is there a workaround other than patching?

Not effectively. Restricting OVS tunnel port operations or limiting local user access reduces attack surface but does not eliminate the vulnerability. Patching is the definitive remedy.

This analysis is based on the published CVE details and vendor advisories as of the modification date. Security impact and affected versions may change; verify current patch availability and applicability with your Linux distribution and OVS vendor. SEC.co makes no warranty regarding completeness or timeliness of information. Organizations should assess risk within their own environment and apply patches per their change management procedures. No exploit code or weaponized proof-of-concept is provided herein. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).

Affected vendors

linux

Weaknesses (CWE)

CWE-667

Related vulnerabilities