CVE-2026-46165

openvswitch: vport: fix self-deadlock on release of tunnel ports

MEDIUM
5.5
CVSS Score
Published: May 28, 2026 at 09:36 AM UTC
Updated: October 30, 2026 at 01:18 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.5
Exploit prediction
EPSS 0.1%

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

6.1.168 ≤ v < 6.1.1756.12.80 ≤ v < 6.12.886.18.21 ≤ v < 6.18.306.19.11 ≤ v < 7.06.6.131 ≤ v < 6.6.1407.0.1 ≤ v < 7.0.742f0d3d81209654c08ffdde5a34b9b92d26458966.1.1686.12.806.18.216.19.116.6.1316931d21f87bc6d657f145798fad0bf077b82486c7.07.0 rc67.0 rc77.17.1 rc17.1 rc298b726ab5e2a4811e27c28e4d041f75bba147eab9d56aced21fb9c104e8a3f3be9b21fbafe448ffcb8c56a3fc5d879c0928f207a756b0f067f06c6a8bbe7bd722bfaea36aab3da6cc60fb4a05c644643
Vendor states this is fixed in 366c482965c673565ecb8bcfb15d5548f13a6a10 (fixed)
Vendor states this is fixed in 3df75fff46b1517eb479d8e6b8e3500763715dd0 (fixed)
Vendor states this is fixed in 6522d59fb7de55ce0f0f285d962243ddffebb01f (fixed)
Vendor states this is fixed in 8ae6c15fc473c9ad03b0173330cce9a092c76154 (fixed)
Vendor states this is fixed in aa69918bd418e700309fdd08509dba324fb24296 (fixed)
Vendor states this is fixed in c741433f6c8dcdecd1d9549d89053761fd1ea413 (fixed)
Vendor states this is fixed in 6.1.175 (unaffected)
Vendor states this is fixed in 6.12.88 (unaffected)
Vendor states this is fixed in 6.18.30 (unaffected)
Affected range stops below 6.20, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.6.140 (unaffected)
Vendor states this is fixed in 7.0 (unaffected)
Vendor states this is fixed in 7.0.7 (unaffected)
Vendor states this is fixed in 7.1 (unaffected)

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-667

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card