https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 10:35:31 +0000 https://vulnerability.circl.lu/vuln/cve-2026-46165 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>openvswitch: vport: fix self-deadlock on release of tunnel ports</p> <p>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&#39;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.</p> <p>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.</p> <p>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()-&gt;netdev_run_todo() while the RTNL itself is already released.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>openvswitch: vport: fix self-deadlock on release of tunnel ports</p> <p>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&#39;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.</p> <p>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.</p> <p>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()-&gt;netdev_run_todo() while the RTNL itself is already released.</p> https://vulnerability.circl.lu/vuln/cve-2026-46165