CVE-2026-74523 in Linux
Summary
by MITRE • 08/15/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability described represents a critical deadlock condition within the qede network driver of the Linux kernel, specifically affecting systems utilizing VXLAN or GENEVE tunneling capabilities. This issue manifests when a transmit timeout occurs on a qede NIC configured with tunnel ports, triggering an improper recovery mechanism that leads to complete system lockup. The problem stems from inadequate synchronization practices during the driver's recovery process, where the same thread attempts to acquire a mutex it already holds, creating an irrecoverable deadlock scenario.
The technical flaw occurs in the qede_recovery_handler function which executes under the rtnetlink lock (rtnl_lock) but subsequently attempts to acquire the driver's internal qede_lock mutex while still holding the rtnl_lock. This creates a classic deadlock situation where the kworker thread becomes blocked on itself, with both locks held indefinitely. The qede_lock is non-recursive, meaning the same thread cannot reacquire it without releasing the first acquisition first. The system exhibits symptoms of complete control plane paralysis as demonstrated in the stack trace showing that tasks like ip commands, ovs-vswitchd, lldpad, and sshd all block waiting for the rtnl_lock that remains unavailable due to the deadlock.
The operational impact of this vulnerability is severe and affects the entire machine's network control plane functionality. While the system may continue to respond to ping requests at the network layer, all higher-level network management operations become completely blocked. This includes IPv6 address configuration, Open vSwitch daemon operations, link layer discovery protocols, and remote access services that depend on the rtnetlink interface. The vulnerability specifically maps to CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and aligns with ATT&CK technique T1490 (Inhibit System Recovery) through its ability to render system management operations unusable.
The mitigation strategy involves reorganizing the recovery process to ensure that internal driver locks are released before attempting to synchronize tunnel ports. The fix moves the udp_tunnel_nic_reset_ntf() call outside of the critical section, allowing the qede_lock to be properly released before calling the udp_tunnel API which requires rtnl_lock. The recovery handler now returns a success indicator, ensuring that port synchronization only occurs when device reloading was successful. This approach mirrors the existing pattern used in qede_open() function and maintains backward compatibility while preventing the deadlock condition. The solution also removes the problematic qede_lock/qede_unlock helper functions since they were exclusively used in this vulnerable code path. This remediation addresses the root cause by ensuring proper lock ordering and prevents the recursive acquisition scenario that led to system-wide paralysis, thereby restoring normal network management functionality while maintaining the integrity of the driver's recovery mechanism.
The vulnerability demonstrates how improper lock management in kernel network drivers can create cascading failures affecting system availability and management capabilities. The fix ensures that the driver maintains its intended behavior for legitimate recovery scenarios while eliminating the deadlock condition that could occur during error recovery operations, thus preserving system stability during normal operation and fault conditions.