CVE-2026-46165
Received Received - Intake
Self-Deadlock in Open vSwitch Kernel Module

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
CVE-2026-46165
EUVD
EUVD-2026-32792
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
openvswitch openvswitch *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel's openvswitch component related to the handling of virtual ports (vports). The issue is a self-deadlock that happens during the release of tunnel ports. Specifically, vports are managed with Read-Copy-Update (RCU) synchronization, and the function netdev_put() must be called after the RCU grace period. However, the current code calls synchronize_net() while holding the RTNL lock, which is problematic for performance and stability.

The deadlock arises because when a device is deleted, rtnl_unlock() calls netdev_run_todo() and blocks until all references are released. But since the RCU callback (call_rcu()) that frees the vport is scheduled after rtnl_unlock(), it never gets executed, causing the vport to never be freed and the reference count to never decrease, resulting in a self-deadlock.

The fix involves moving the RCU callback scheduling before rtnl_unlock(), ensuring the callback executes when synchronize_net() is called from rtnl_unlock()->netdev_run_todo(), after the RTNL lock is released, thus preventing the deadlock.


How can this vulnerability impact me? :

This vulnerability can cause a self-deadlock in the Linux kernel when releasing tunnel ports in openvswitch. This deadlock can lead to system instability or a hang during device removal operations, potentially impacting network functionality and system performance.

In environments relying on openvswitch for network virtualization or tunneling, this could result in degraded service availability or require system reboots to recover from the deadlock.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by ensuring that the RCU callback is scheduled before rtnl_unlock(), allowing the vport to be properly freed and preventing self-deadlock on device removal.

To mitigate this vulnerability, update the Linux kernel or the openvswitch component to a version that includes this fix.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart