CVE-2026-46165: Linux kernel · openvswitch: vport: fix self-deadlock on release of tunnel ports
Source GCVE Database
Not known to be exploited · CVSS 5.5 High · fixed in c741433f6c8dcdecd1d9549d89053761fd1ea413 : patch Linux kernel soon.
Data as of 30 Oct 2026, 16:33 UTC
Thin evidence
One scorer or none- Patch
- Available – fixed in c741433f6c8dcdecd1d9549d89053761fd1ea413, aa69918bd418e700309fdd08509dba324fb24296, 3600033f31b1afa16d73a24905eec9ee1d222b97 +9
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 28 May 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Linuxlinux/kernelpkg:deb/linux/kernelOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
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.
References
- nvd.nist.gov/vuln/detail/CVE-2026-46165 (opens in a new tab)
- cert-portal.siemens.com/productcert/html/ssa-784472.html (opens in a new tab)
- git.kernel.org/stable/c/3600033f31b1afa16d73a24905eec9ee1d222b97 (opens in a new tab)
- git.kernel.org/stable/c/366c482965c673565ecb8bcfb15d5548f13a6a10 (opens in a new tab)
- git.kernel.org/stable/c/3df75fff46b1517eb479d8e6b8e3500763715dd0 (opens in a new tab)
- git.kernel.org/stable/c/6522d59fb7de55ce0f0f285d962243ddffebb01f (opens in a new tab)
- git.kernel.org/stable/c/8ae6c15fc473c9ad03b0173330cce9a092c76154 (opens in a new tab)
- git.kernel.org/stable/c/aa69918bd418e700309fdd08509dba324fb24296 (opens in a new tab)
- git.kernel.org/stable/c/c741433f6c8dcdecd1d9549d89053761fd1ea413 (opens in a new tab)