CVE-2026-46165
5.5 MEDIUMIn the Linux kernel, the following vulnerability has been resolved: openvswitch: vport: fix self-deadlock on release of tunnel ports vp...
Published: 2026-05-28 · Last updated: 2026-06-10
Severity and scoring
- CVSS
- 5.5 MEDIUM
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- CWE
- CWE-667
Affected products
| Vendor | Product |
|---|---|
| linux | linux_kernel |
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.
Source: NVD
References
- [NVD]https://nvd.nist.gov/vuln/detail/CVE-2026-46165
- [Patch]https://git.kernel.org/stable/c/366c482965c673565ecb8bcfb15d5548f13a6a10
- [Patch]https://git.kernel.org/stable/c/3df75fff46b1517eb479d8e6b8e3500763715dd0
- [Patch]https://git.kernel.org/stable/c/6522d59fb7de55ce0f0f285d962243ddffebb01f
- [Patch]https://git.kernel.org/stable/c/8ae6c15fc473c9ad03b0173330cce9a092c76154
- [Patch]https://git.kernel.org/stable/c/aa69918bd418e700309fdd08509dba324fb24296
- [Patch]https://git.kernel.org/stable/c/c741433f6c8dcdecd1d9549d89053761fd1ea413
Related CVEs
Same vendor
- CVE-2026-46273 — In the Linux kernel, the following vulnerability has been resolved: ibmveth: Disable GSO for packets with small MSS Some physical adapt... (8.6 HIGH)
- CVE-2026-46272 — In the Linux kernel, the following vulnerability has been resolved: coresight: tmc-etr: Fix race condition between sysfs and perf mode ... (4.7 MEDIUM)
- CVE-2026-46271 — In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: do WoW offloads only on primary link In case of multi... (7.8 HIGH)
- CVE-2026-46270 — In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: Fix use-after-free in power_supply_changed() ... (8.4 HIGH)
- CVE-2026-46269 — In the Linux kernel, the following vulnerability has been resolved: pinctrl: canaan: k230: Fix NULL pointer dereference when parsing dev... (5.5 MEDIUM)
Same CWE
- CVE-2026-46262 — In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl_xcvr: Revert fix missing lock in fsl_xcvr_mode_put() This... (5.5 MEDIUM)
- CVE-2026-46256 — In the Linux kernel, the following vulnerability has been resolved: NFS/localio: prevent direct reclaim recursion into NFS via nfs_write... (5.5 MEDIUM)
- CVE-2026-46252 — In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error pat... (5.5 MEDIUM)
- CVE-2026-46156 — In the Linux kernel, the following vulnerability has been resolved: LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang() The s... (5.5 MEDIUM)
- CVE-2026-24182 — NVIDIA Display Driver for Windows and Linux contains a vulnerability where an attacker could leak held driver locks (6.5 MEDIUM)