CVE-2026-74523: qede: sync udp_tunnel ports outside qede_lock in the recovery path

Greg Kroah-Hartman <[email protected]>
Newsgroups org.kernel.vger.linux-cve-announce
Message-ID <2026081545-CVE-2026-74523-125d@gregkh>
From: Greg Kroah-Hartman <[email protected]>

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.

The Linux kernel CVE team has assigned CVE-2026-74523 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.9 with commit 8cd160a29415f1789d473b1dc07fcc9d02a02b87 and fixed in 6.6.151 with commit e382a4efeeae6555b95d9ff336cf3094ee7d336b
	Issue introduced in 5.9 with commit 8cd160a29415f1789d473b1dc07fcc9d02a02b87 and fixed in 6.12.103 with commit 4626df3f63c9185efba5750fe76ac01ab3351bae
	Issue introduced in 5.9 with commit 8cd160a29415f1789d473b1dc07fcc9d02a02b87 and fixed in 6.18.44 with commit e51becb8f3377a377171ed5bf0082b96e22e6292
	Issue introduced in 5.9 with commit 8cd160a29415f1789d473b1dc07fcc9d02a02b87 and fixed in 7.1.8 with commit 6f1ef8170d3d8ad9319aa01347945dcdf5cc4f27
	Issue introduced in 5.9 with commit 8cd160a29415f1789d473b1dc07fcc9d02a02b87 and fixed in 7.2-rc6 with commit 451c9075d6c53f2438d110addbeeeea6fac18567

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-74523
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/net/ethernet/qlogic/qede/qede_main.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/e382a4efeeae6555b95d9ff336cf3094ee7d336b
	https://git.kernel.org/stable/c/4626df3f63c9185efba5750fe76ac01ab3351bae
	https://git.kernel.org/stable/c/e51becb8f3377a377171ed5bf0082b96e22e6292
	https://git.kernel.org/stable/c/6f1ef8170d3d8ad9319aa01347945dcdf5cc4f27
	https://git.kernel.org/stable/c/451c9075d6c53f2438d110addbeeeea6fac18567
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.