Skip to main content

Linux Kernel CVE-2026-46165

| EUVDEUVD-2026-32792 MEDIUM
Improper Locking (CWE-667)
2026-05-28 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-gwmf-r7m2-pphm
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.4 MEDIUM

Deleting OVS tunnel vports requires root-level or explicit CAP_NET_ADMIN administrative privilege (PR:H); impact is availability-only with no data exposure or integrity modification.

3.1 AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative
Red Hat
5.5 LOW
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 10, 2026 - 21:36 vuln.today
CVSS changed
Jun 10, 2026 - 21:22 NVD
5.5 (MEDIUM)
Patch available
May 28, 2026 - 12:01 EUVD
CVE Published
May 28, 2026 - 10:16 nvd
UNKNOWN (no severity yet)
CVE Published
May 28, 2026 - 10:16 nvd
MEDIUM 5.5

DescriptionNVD

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.

AnalysisAI

OpenVSwitch tunnel port removal in the Linux kernel triggers a self-deadlock that permanently hangs the kernel's RTNL lock, causing a denial of service requiring system reboot. The flaw affects systems across multiple stable kernel branches (6.6.x, 6.12.x, 6.18.x, 7.0.x) where OVS tunnel vports (VXLAN, GRE, GENEVE) are actively managed. Patched versions are available across all affected stable branches; no public exploit identified at time of analysis, and the EPSS score of 0.02% (5th percentile) indicates negligible observed exploitation probability.

Technical ContextAI

The vulnerability (CWE-667: Improper Locking) resides in the Linux kernel's OpenVSwitch (OVS) subsystem, specifically in the vport lifecycle management for tunnel-type virtual ports. vports are reference-counted, RCU (Read-Copy-Update)-protected kernel objects shared concurrently across execution contexts. The correct teardown sequence requires: rtnl_delete_link() under the RTNL lock to remove the netdev, followed by netdev_put() after an RCU grace period via call_rcu(). The bug arises because call_rcu() was positioned after rtnl_unlock(), but rtnl_unlock() internally invokes netdev_run_todo(), which blocks until all netdev references reach zero. The only code that would drop those references is the RCU callback - which was never scheduled because call_rcu() had not yet executed. This circular dependency constitutes a self-deadlock. The kernel fix reorders call_rcu() to execute before rtnl_unlock(), so the RCU callback is queued and fires during synchronize_net() inside netdev_run_todo() once the RTNL has already been released. Affected CPE: cpe:2.3:o:linux:linux_kernel across all identified version ranges.

RemediationAI

The primary remediation is to upgrade to a patched kernel version: 6.6.140, 6.12.88, 6.18.30, 7.0.7, or 7.1-rc3 as applicable. Upstream patch commits are publicly available at git.kernel.org/stable: 366c482965c673565ecb8bcfb15d5548f13a6a10, 3df75fff46b1517eb479d8e6b8e3500763715dd0, 6522d59fb7de55ce0f0f285d962243ddffebb01f, aa69918bd418e700309fdd08509dba324fb24296, c741433f6c8dcdecd1d9549d89053761fd1ea413, and 8ae6c15fc473c9ad03b0173330cce9a092c76154. For environments where immediate patching is not possible, the targeted compensating control is to avoid live deletion of OVS tunnel vports (VXLAN, GRE, GENEVE) during normal operation - instead, schedule port lifecycle changes at planned maintenance windows with full OVS service restarts rather than incremental port removal. Restricting CAP_NET_ADMIN to root-only and auditing which processes can invoke OVS management commands limits the attacker surface, though this may impact orchestration tooling. No workaround fully eliminates the deadlock risk short of applying the upstream kernel patch.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected

Share

CVE-2026-46165 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy