CVE-2026-74523 - Vulnerability Details

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

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.

Published: 2026-08-15

Score: 7.5 High

EPSS: < 1% Very Low

KEV: No

Impact:

Action:

Analysis

Impact

The qede driver for Linux kernel networking devices contains a deadlock bug that is triggered when a TX timeout occurs on a NIC with VXLAN/GENEVE tunnel ports. The recovery path takes a mutex that is already held by the same task, causing a self‑deadlock. This locks all users of the rtnl_lock, blocking network configuration commands, VLAN management, SSH, and other critical network stack functions, while basic services such as ping continue to operate. The result is a denial of service that renders the system’s control plane unusable until a reboot.

Affected Systems

The vulnerability is present in the Linux kernel's qede driver, which supports VXLAN/GENEVE tunneling on compatible NICs. No specific kernel version list is supplied, but any kernel build that includes the unpatched qede driver code is affected, including production nodes observed with the issue.

Risk and Exploitability

Risk and Exploitability: The CVSS score of 7.5 indicates high severity. The EPSS score of < 1% suggests that exploitation is very unlikely, though nonzero. The vulnerability is not listed in the CISA KEV catalog. The likely attack vector is local or network‑based; an adversary can trigger a TX timeout by manipulating traffic or misconfiguring tunnel ports. Once triggered, it causes a self‑deadlock that blocks all tasks holding rtnl_lock, leading to a severe denial of service that remains until reboot or driver reload.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`8cd160a29415f1789d473b1dc07fcc9d02a02b87`	affected	< 19e505ee8bb9e0f0355eda9e9f614fb25fed0070
`8cd160a29415f1789d473b1dc07fcc9d02a02b87`	affected	< c4c1e5d6bc2b900b2328d6fff93dc8146b858d69
`8cd160a29415f1789d473b1dc07fcc9d02a02b87`	affected	< 8e1bdf57de91247e57816482966265ada573cc74
`8cd160a29415f1789d473b1dc07fcc9d02a02b87`	affected	< e382a4efeeae6555b95d9ff336cf3094ee7d336b
`8cd160a29415f1789d473b1dc07fcc9d02a02b87`	affected	< 4626df3f63c9185efba5750fe76ac01ab3351bae
`8cd160a29415f1789d473b1dc07fcc9d02a02b87`	affected	< e51becb8f3377a377171ed5bf0082b96e22e6292
`8cd160a29415f1789d473b1dc07fcc9d02a02b87`	affected	< 6f1ef8170d3d8ad9319aa01347945dcdf5cc4f27
`8cd160a29415f1789d473b1dc07fcc9d02a02b87`	affected	< 451c9075d6c53f2438d110addbeeeea6fac18567

Linux

affected

Version	Status	Constraints
`5.9`	affected	—
`0`	unaffected	< 5.9
`5.10.265`	unaffected	≤ 5.10.*
`5.15.216`	unaffected	≤ 5.15.*
`6.1.183`	unaffected	≤ 6.1.*
`6.6.151`	unaffected	≤ 6.6.*
`6.12.103`	unaffected	≤ 6.12.*
`6.18.44`	unaffected	≤ 6.18.*
`7.1.8`	unaffected	≤ 7.1.*
`7.2`	unaffected	≤ *

No data.

Vendor Product Confidence Versions

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`[8cd160a29415f1789d473b1dc07fcc9d02a02b87,e382a4efeeae6555b95d9ff336cf3094ee7d336b)`	affected	code_commit	—
`[8cd160a29415f1789d473b1dc07fcc9d02a02b87,4626df3f63c9185efba5750fe76ac01ab3351bae)`	affected	code_commit	—
`[8cd160a29415f1789d473b1dc07fcc9d02a02b87,e51becb8f3377a377171ed5bf0082b96e22e6292)`	affected	code_commit	—
`[8cd160a29415f1789d473b1dc07fcc9d02a02b87,6f1ef8170d3d8ad9319aa01347945dcdf5cc4f27)`	affected	code_commit	—
`[8cd160a29415f1789d473b1dc07fcc9d02a02b87,451c9075d6c53f2438d110addbeeeea6fac18567)`	affected	code_commit	—

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`5.9`	affected	generic	—
`[0,5.9)`	unaffected	generic	—
`[6.6.151,6.7.0)`	unaffected	semver	—
`[6.12.103,6.13.0)`	unaffected	semver	—
`[6.18.44,6.19.0)`	unaffected	semver	—
`[7.1.8,7.2.0)`	unaffected	semver	—
`[7.2-rc6,*]`	unaffected	generic	—

Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

Update the Linux kernel to the latest stable release that contains the qede driver fix
If an immediate kernel upgrade is not possible, unload or disable the qede driver on affected interfaces to avoid the recovery deadlock
Prior to patching, do not create or enable VXLAN/GENEVE tunnels on the NICs that use qede
Continuously monitor kernel logs (dmesg) for qede TX timeout warnings and take corrective action

Generated by OpenCVE AI on August 22, 2026 at 01:49 UTC.

Tracking

Sign in to view the affected projects.

Advisories

Source	ID	Title
Debian DSA	DSA-6466-1	linux security update

No CVSS v4.0

Attack Vector Network

Attack Complexity Low

Privileges Required None

Scope Unchanged

Confidentiality Impact None

Integrity Impact None

Availability Impact High

User Interaction None

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

The EPSS score is 0.00501.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/19e505ee8bb9e0f0355eda9e9f614fb25fed0070
https://git.kernel.org/stable/c/451c9075d6c53f2438d110addbeeeea6fac18567
https://git.kernel.org/stable/c/4626df3f63c9185efba5750fe76ac01ab3351bae
https://git.kernel.org/stable/c/6f1ef8170d3d8ad9319aa01347945dcdf5cc4f27
https://git.kernel.org/stable/c/8e1bdf57de91247e57816482966265ada573cc74
https://git.kernel.org/stable/c/c4c1e5d6bc2b900b2328d6fff93dc8146b858d69
https://git.kernel.org/stable/c/e382a4efeeae6555b95d9ff336cf3094ee7d336b
https://git.kernel.org/stable/c/e51becb8f3377a377171ed5bf0082b96e22e6292
https://lore.kernel.org/linux-cve-announce/2026081545-CVE-2026-74523-125d@gregkh/T
https://nvd.nist.gov/vuln/detail/CVE-2026-74523
https://www.cve.org/CVERecord?id=CVE-2026-74523

History

Sat, 22 Aug 2026 00:15:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-833
References		https://lore.kernel.org/linux-cve-announce/2026081545-CVE-2026-74523-125d@gregkh/T https://nvd.nist.gov/vuln/detail/CVE-2026-74523 https://www.cve.org/CVERecord?id=CVE-2026-74523
Metrics	threat_severity `None`	threat_severity `Moderate`

Wed, 19 Aug 2026 17:00:00 +0000

Type	Values Removed	Values Added
References		https://git.kernel.org/stable/c/19e505ee8bb9e0f0355eda9e9f614fb25fed0070 https://git.kernel.org/stable/c/8e1bdf57de91247e57816482966265ada573cc74 https://git.kernel.org/stable/c/c4c1e5d6bc2b900b2328d6fff93dc8146b858d69

Mon, 17 Aug 2026 14:15:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-362

Mon, 17 Aug 2026 12:30:00 +0000

Type	Values Removed	Values Added
Weaknesses	CWE-362

Mon, 17 Aug 2026 06:00:00 +0000

Type	Values Removed	Values Added
Metrics		cvssV3_1 `{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}`

Sat, 15 Aug 2026 16:30:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-362

Sat, 15 Aug 2026 12:45:00 +0000

Type	Values Removed	Values Added
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.
Title		qede: sync udp_tunnel ports outside qede_lock in the recovery path
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/451c9075d6c53f2438d110addbeeeea6fac18567 https://git.kernel.org/stable/c/4626df3f63c9185efba5750fe76ac01ab3351bae https://git.kernel.org/stable/c/6f1ef8170d3d8ad9319aa01347945dcdf5cc4f27 https://git.kernel.org/stable/c/e382a4efeeae6555b95d9ff336cf3094ee7d336b https://git.kernel.org/stable/c/e51becb8f3377a377171ed5bf0082b96e22e6292

Subscriptions

Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-08-15T12:27:40.575Z

Updated: 2026-08-19T16:38:27.388Z

Reserved: 2026-08-15T05:44:03.911Z

Link: CVE-2026-74523

Vulnrichment

No data.

NVD

Status : Received

Published: 2026-08-15T13:17:57.543

Modified: 2026-08-19T17:21:09.017

Link: CVE-2026-74523

Redhat

Severity : Moderate

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-74523 - Bugzilla

OpenCVE Enrichment

Updated: 2026-08-22T02:00:17Z

Weaknesses

CWE-362
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
CWE-833
Deadlock

Impact

Affected Systems

Risk and Exploitability

Tracking

Attack Vector Network

Attack Complexity Low

Privileges Required None

Scope Unchanged

Confidentiality Impact None

Integrity Impact None

Availability Impact High

User Interaction None

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object