Threats Tagged 'cve-2025-40347'
View all threats tagged with 'cve-2025-40347'. Filter and sort to focus on specific types of threats.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Threats Tagged 'cve-2025-40347'
Click on any threat for detailed analysis and mitigation recommendations
A deadlock vulnerability in the Linux kernel's enetc network driver was resolved. The issue occurs due to recursive acquisition of the enetc_mdio_lock read lock, leading to thread hangs on the LS1028A platform with RT kernels after a specific workaround was applied. The deadlock arises when a higher-priority writer waits on the lock while readers attempt recursive acquisition, causing a hang. The fix prevents recursive lock acquisition to avoid the deadlock. Join the discussion | GCVE Database | 12/16/2025, 15:30:42 UTC Added: 07/30/2026, 15:50:44 UTC |
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. Join the discussion | GCVE Database | 12/16/2025, 14:15:00 UTC Added: 07/18/2026, 11:34:39 UTC |
Showing 1 to 2 of 2 results