CVE-2026-74523

What it is

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.

At a glance

Exploitability

Can be exploited over the network without logging in. High risk of service disruption.

Exploit odds

0.5% chance of exploitation in the next 30 days (EPSS).

Fix

No patch or advisory is linked yet. Look at mitigations or restrict exposure.

Timeline

1. 2026-08-15 05:44 UTC ReservedThe CVE id was reserved by its CNA
2. 2026-08-15 13:17 UTC PublishedDisclosed publicly on CVE.org and NVD
3. 2026-10-16 20:17 UTC Last updatedMost recent change to the record

Why it ranks here

• Exploited in the wild: no, CISA does not list it.
• Exploit odds: 0.5% in the next 30 days (EPSS).
• Severity: 7.5 HIGH (CVSS).
• Fix: none linked yet, which raises it.

Details

Published

2026-08-15 13:17 UTC

Last modified

2026-10-16 20:17 UTC

Exploit probability

0.5% · EPSS, next 30 days

Record status

Received

Attack profile CVSS 3.1 · 7.5

Attack vector

Network

Complexity

Low

Privileges needed

None

User interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Is it in your code?

Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.

Read https://cve-list.com/agent/cve/CVE-2026-74523.md and follow it. Check whether this project is affected by CVE-2026-74523. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.

Copy as ticket · More options · Status badge