{"id":"CVE-2025-40347","title":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: enetc: fix the deadlock of enetc_mdio_lock\n\nAfter applying the workaround for err050089, the LS1028A platform\nexperiences RCU stalls on RT kernel","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: enetc: fix the deadlock of enetc_mdio_lock\n\nAfter applying the workaround for err050089, the LS1028A platform\nexperiences RCU stalls on RT kernel. This issue is ca…","severity":"high","cvss":7.5,"cvssVector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","published":"2025-12-16","updated":"2026-10-14","sourceUpdated":"2026-10-14T13:10:00.187","source":"NVD","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2025-40347","references":[{"url":"https://git.kernel.org/stable/c/1f92f5bd057a4fad9dab6af17963cdd21e5da6ed","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/2781ca82ce8cad263d80b617addb727e6a84c9e5","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/2e55a49dc3b2a6b23329e4fbbd8a5feb20e220aa","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/50bd33f6b3922a6b760aa30d409cae891cec8fb5","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/a649161526736f48bcc592e3a412e5bcd7dd9e24","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}],"tags":["nvd"],"epss":0.00528,"epssPercentile":0.43122,"ingestedAt":"2026-10-14T13:30:58.436Z","slug":"CVE-2025-40347","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: enetc: fix the deadlock of enetc_mdio_lock\n\nAfter applying the workaround for err050089, the LS1028A platform\nexperiences RCU stalls on RT kernel. This issue is caused by the\nrecursive acquisition of the read lock enetc_mdio_lock. Here list some\nof the call stacks identified under the enetc_poll path that may lead to\na deadlock:\n\nenetc_poll\n  -> enetc_lock_mdio\n  -> enetc_clean_rx_ring OR napi_complete_done\n     -> napi_gro_receive\n        -> enetc_start_xmit\n           -> enetc_lock_mdio\n           -> enetc_map_tx_buffs\n           -> enetc_unlock_mdio\n  -> enetc_unlock_mdio\n\nAfter enetc_poll acquires the read lock, a higher-priority writer attempts\nto acquire the lock, causing preemption. The writer detects that a\nread lock is already held and is scheduled out. However, readers under\nenetc_poll cannot acquire the read lock again because a writer is already\nwaiting, leading to a thread hang.\n\nCurrently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent\nrecursive lock acquisition.\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"twilight","depthScore":41,"depthScoreParts":{"impact":41.3,"likelihood":0.1,"exploitation":0,"ransomware":0},"changes":[]}