CVE-2026-74523

In the Linux kernel, the following vulnerability has been resolved:

qede: sync udptunnel ports outside qedelock 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 [qedetxtimeout:586(ens6f1)]TX timeout on queue 2! [qederecoveryhandler:2665(ens6f0)]Starting a recovery process

The recovery path deadlocks on the driver's own mutex:

qedesptask rtnllock() mutexlock(&edev->qedelock) <- taken qederecoveryhandler qedeload udptunnelnicresetntf __udptunnelnicdevicesync info->synctable == qedeudptunnelsync mutexlock(&edev->qedelock) <- same task: deadlock

The mutex is not recursive, so the kworker blocks on itself with rtnllock held, and neither lock is ever released. Every task that calls rtnllock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnlmutex.owner decodes to the very kworker blocked at the innermost mutexlock() above.

Re-sync the tunnel ports from qedesptask() after the internal lock is dropped, still under rtnllock as the udptunnel API requires. This mirrors qedeopen(), which calls udptunnelnicreset_ntf() under rtnl without the internal lock.

qederecoveryhandler() 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 udptunnelnicresetntf() call before either.

This was the only user of the qedelock()/qedeunlock() helpers, so remove them.