Look up another CVE · open CVE-2026-74523 in the interactive tracker

CVE-2026-74523

qede: sync udp_tunnel ports outside qede_lock in the recovery path

7.5 EPSS 0.5% AV:N

Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-74523 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	fixedDLA-4777-1 · 2026-09-08 · text	6.1.187-1	Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixie	fixedDSA-6466-1 · 2026-08-25 · text	6.12.105-1	Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.1.8-1	Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.8-1	Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12	fixedDLA-4788-1 · 2026-09-19 · text	6.12.107-1~deb12u1	Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/net/ethernet/qlogic/qede/qede_main.c

What this is: QLOGIC QL4xxx ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/qlogic/qede/ · netdev@vger.kernel.org · Orphan
Kernel module: qede

Check it on the machine

grep -wE 'CONFIG_ETHERNET|CONFIG_NET_VENDOR_QLOGIC|CONFIG_QEDE' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w qede

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi
forky, sid, bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64

M: a module where it is built at all; some flavours do not build it

Build switches: CONFIG_ETHERNET, CONFIG_NET_VENDOR_QLOGIC, CONFIG_QEDE
Reads as: all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-08-15 (2 months ago)source
CVSS: 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.50%, higher than 41.6% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: drivers/net

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
5.9	5.10.265	19e505ee8bb9
5.9	5.15.216	c4c1e5d6bc2b
5.9	6.1.183	8e1bdf57de91
5.9	6.6.151	e382a4efeeae
5.9	6.12.103	4626df3f63c9
5.9	6.18.44	e51becb8f337
5.9	7.1.8	6f1ef8170d3d
5.9	7.2	451c9075d6c5

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4788-1	2026-09-19	bookworm 6.12.107-1~deb12u1	tracker
DLA-4777-1	2026-09-08	bookworm 6.1.187-1	tracker
DSA-6466-1	2026-08-25	trixie 6.12.105-1	tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network: The bug is reached from the qede NIC firmware error-recovery path triggered by network-driven faults (e.g., TX queue watchdog timeout on traffic-bearing queues); remote packets to an internet-facing qede host can induce recovery without local syscall access.
AC:LAttack complexity, low: Once qede recovery runs on an interface with VXLAN/GENEVE ports registered, the nested qede_lock while rtnl_lock is held deadlocks deterministically; attackers can repeatedly apply traffic/load patterns to provoke TX timeout and firmware ERROR_RECOVERY.
PR:NPrivileges required, none: Exploitation requires only the ability to send network traffic that provokes NIC recovery on a target that already has VXLAN/GENEVE offloads configured (normal on cloud/DC qede nodes); no attacker privileges or rtnetlink configuration are needed.
UI:NUser interaction, none: No victim interaction is required beyond routine use of a server whose qede uplink already runs overlay networking; the attacker does not need the victim to mount, open, or approve anything at exploit time.
S:UScope, unchanged: Impact is a kernel networking control-plane deadlock within the same host/kernel trust boundary; it does not cross VM, container, or IOMMU security domains to affect other authorities.
C:NConfidentiality impact, none: This is a locking deadlock with no memory corruption, out-of-bounds access, use-after-free, or information disclosure; only mutex/RTNL state is wedged.
I:NIntegrity impact, none: The flaw does not modify data or achieve code execution; it only blocks threads waiting on rtnl_lock/qede_lock without altering memory contents or kernel objects beyond stalled lock state.
A:HAvailability impact, high: The deadlock holds rtnl_lock indefinitely, freezing system-wide network reconfiguration and management (ip, ovs-vswitchd, sshd addr setup) until reboot; per CVSS guidance, kernel deadlocks that deny critical availability are rated High.