CVE-2026-74523

Status: UPDATED  |  Advisory ID: CVE-2026-74523

Key Details

Affected Products, Subsystems & Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References