Multiple Locks of a Critical Resource The advisory has been revoked - it doesn't affect any version of package kernel-headers (opens in a new tab)
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-KERNELHEADERS-14451403
- published17 Dec 2025
- disclosed16 Dec 2025
Introduced: 16 Dec 2025
CVE-2025-40347 (opens in a new tab)Amendment
The Red Hat security team deemed this advisory irrelevant for RHEL:10.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-headers package and not the kernel-headers package as distributed by RHEL.
In the Linux kernel, the following vulnerability has been resolved:
net: enetc: fix the deadlock of enetc_mdio_lock
After applying the workaround for err050089, the LS1028A platform experiences RCU stalls on RT kernel. This issue is caused by the recursive acquisition of the read lock enetc_mdio_lock. Here list some of the call stacks identified under the enetc_poll path that may lead to a deadlock:
enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdio
After enetc_poll acquires the read lock, a higher-priority writer attempts to acquire the lock, causing preemption. The writer detects that a read lock is already held and is scheduled out. However, readers under enetc_poll cannot acquire the read lock again because a writer is already waiting, leading to a thread hang.
Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent recursive lock acquisition.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2422720
- https://access.redhat.com/security/cve/CVE-2025-40347
- https://git.kernel.org/stable/c/1f92f5bd057a4fad9dab6af17963cdd21e5da6ed
- https://git.kernel.org/stable/c/2781ca82ce8cad263d80b617addb727e6a84c9e5
- https://git.kernel.org/stable/c/2e55a49dc3b2a6b23329e4fbbd8a5feb20e220aa
- https://git.kernel.org/stable/c/50bd33f6b3922a6b760aa30d409cae891cec8fb5
- https://git.kernel.org/stable/c/a649161526736f48bcc592e3a412e5bcd7dd9e24