Description

In the Linux kernel, the following vulnerability has been resolved: qede: sync udp_tunnel ports outside qede_lock in the recovery path A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-15T13:17:57.543Z",
  "pubdate": "2026-08-15T13:17:57.543Z",
  "executiveSummary": "A deadlock vulnerability exists in the Linux kernel qede network driver recovery path. The flaw is classified as a concurrency and locking vulnerability resulting in a Denial of Service condition.\nThe vulnerability occurs when a transmit queue timeout triggers the qede_recovery_handler, which attempts to acquire a non-recursive mutex (edev->qede_lock) while already holding it or while it is locked within the same execution context under the rtnl_lock.\nThis causes the kernel worker thread to deadlock on itself. As a result, the rtnetlink control plane of the entire machine becomes completely wedged, blocking all subsequent tasks that attempt to acquire the rtnl_lock such as ip, ovs-vswitchd, lldpad, IPv6 addrconf, and sshd.\nWhile network packet forwarding or basic ping responses may persist, administrative control and interface configuration capabilities are severely impacted.\nThe vulnerability affects systems utilizing the qede network interface card driver with VXLAN or GENEVE tunnel ports configured.\nExploitation does not require remote attacker capabilities or specialized authentication; it is triggered locally by a hardware or driver-level transmission timeout condition that initiates the internal recovery workflow.",
  "technicalDetails": "The vulnerable component is the qede network driver in the Linux kernel, specifically within the recovery and slow-path task execution logic located in functions such as qede_sp_task(), qede_recovery_handler(), qede_load(), and udp_tunnel_nic_reset_ntf().\nThe root cause stems from incorrect lock ordering and re-entrancy on the driver's internal mutex, edev->qede_lock, during the device recovery sequence. When a network transmission timeout occurs (NETDEV WATCHDOG: transmit queue timed out), the driver schedules a slow-path task via qede_sp_task(), which acquires the global rtnl_lock and subsequently takes the driver-specific edev->qede_lock.\nDuring the execution of qede_recovery_handler(), the driver invokes qede_load() followed by udp_tunnel_nic_reset_ntf() and __udp_tunnel_nic_device_sync(), which attempts to execute the callback info->sync_table == qede_udp_tunnel_sync(). This callback attempts to acquire the same edev->qede_lock that is already held by the current task.\nBecause the edev->qede_lock is a non-recursive mutex, the kworker thread blocks indefinitely on itself while continuing to hold the rtnl_lock.\nThe step-by-step attack or failure flow proceeds as follows: 1. A TX timeout is detected on a qede NIC configured with VXLAN or GENEVE tunnel ports. 2. The kernel initiates the network watchdog recovery mechanism, calling qede_recovery_handler() inside qede_sp_task() under the rtnl_lock. 3. The recovery routine calls device load and tunnel reset functions that attempt to acquire edev->qede_lock. 4. A self-deadlock occurs on edev->qede_lock. 5. Because the rtnl_lock is held by the deadlocked kworker and never released, any administrative utility or daemon attempting to modify network configurations via netlink (such as ip, ovs-vswitchd, lldpad, or sshd session setup dependent on network configuration) blocks permanently. 6. The machine control plane becomes unresponsive, leading to a localized Denial of Service requiring a hard reboot or kernel intervention."
}