Deadlock Affecting kernel-rt-64k package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL10-KERNELRT64K-19207778
- published23 Aug 2026
- disclosed15 Aug 2026
Introduced: 15 Aug 2026
NewCVE-2026-74523 (opens in a new tab)How to fix?
There is no fixed version for RHEL:10 kernel-rt-64k.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-rt-64k package and not the kernel-rt-64k package as distributed by RHEL.
See How to fix? for RHEL:10 relevant fixed versions and status.
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.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2517009
- https://access.redhat.com/security/cve/CVE-2026-74523
- 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
- https://git.kernel.org/stable/c/19e505ee8bb9e0f0355eda9e9f614fb25fed0070
- https://git.kernel.org/stable/c/8e1bdf57de91247e57816482966265ada573cc74
- https://git.kernel.org/stable/c/c4c1e5d6bc2b900b2328d6fff93dc8146b858d69