CVE-2026-74523
Received Received - Intake

BaseFortify

Publication date: 2026-08-15

Last updated on: 2026-08-15

Assigner: kernel.org

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-15
Last Modified
2026-08-15
Generated
2026-08-15
AI Q&A
2026-08-15
EPSS Evaluated
N/A
NVD
CVE-2026-74523
EUVD
EUVD-2026-59716

Affected Vendors & Products

Currently, no data is known.

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability is a deadlock in the Linux kernel's qede network driver. A TX timeout on a qede NIC with VXLAN/GENEVE tunnel ports causes the recovery process to deadlock on a mutex. The driver's recovery handler tries to acquire a mutex it already holds while holding the rtnl_lock, causing a self-deadlock. This locks up the entire machine's network control plane, preventing further network operations.

Detection Guidance

This vulnerability is specific to the qede NIC driver in the Linux kernel and manifests as a deadlock during recovery after a TX timeout on a NIC with VXLAN/GENEVE tunnel ports. Detection requires checking kernel logs for qede-related errors like 'transmit queue timed out' or 'recovery process' messages.

Impact Analysis

If exploited, this vulnerability can cause a complete system lockup where the machine remains responsive to pings but all network operations freeze. This includes tasks like IP configuration, Open vSwitch, SSH, and IPv6 address configuration. The system may require a hard reboot to recover.

Mitigation Strategies

Apply the kernel patch that resolves this issue. Ensure your qede NIC driver is updated to a version where the recovery path no longer deadlocks. Avoid using VXLAN/GENEVE tunnel ports on qede NICs until patched.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-74523. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart