CVE-2026-46165Medium· 5.5▾ SunlitIn 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 per…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 30.3 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Oct 15.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.1%
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.
linux_kernel >= 6.1.168, < 6.1.175linux_kernel >= 6.6.131, < 6.6.140linux_kernel >= 6.12.80, < 6.12.88linux_kernel >= 6.18.21, < 6.18.30linux_kernel >= 6.19.11, < 7.0linux_kernel >= 7.0.1, < 7.0.7linux_kernel = 7.0linux_kernel = 7.1Upgrade past the affected range:
linux_kernel 7.0.7Connected by shared product, vendor, weakness, or advisory.
CVE-2022-49742Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: f2fs: initialize locks earlier in f2fs_fill_super() syzbot is reporting lockdep warning at f2fs_handle_error() [1], for spin_lock(&sbi->error_lock) is called before sp…
CVE-2022-3303Medium· 4.7A race condition flaw was found in the Linux kernel sound subsystem due to improper locking
CVE-2022-2959High· 7.0A race condition was found in the Linux kernel's watch queue due to a missing lock in pipe_resize_ring()
CVE-2022-3028High· 7.0A race condition was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem) when multiple calls to xfrm_probe_algs occurred simultaneously
CVE-2023-53292Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_none After grabbing q->sysfs_lock, q->elevator may become NULL because of elevator switch. Fix the NU…
CVE-2025-71309Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix deadlock in ni_read_folio_cmpr Syzbot reported a task hung in ni_readpage_cmpr (now ni_read_folio_cmpr). This is caused by a lock inversion deadlock invo…