Skip to main content

Threats Tagged 'cve-2025-40347'

View all threats tagged with 'cve-2025-40347'. Filter and sort to focus on specific types of threats.

Pro Console Lifetime

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)

View Plans & Pricing

API access activates after upgrading in Console -> Billing.

Breach by OffSeqOFFSEQFRIENDS — 25% OFF

Check if your credentials are on the dark web

Instant breach scanning across billions of leaked records. Free tier available.

Scan now

Filter Threats

Narrow down the results by type, severity, or affected countries

Search threats by title, CVE ID, or description. Maximum 100 characters.
Active filters (1):Tag: cve-2025-40347

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

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

Showing 1 to 2 of 2 results

Filters:Tag: cve-2025-40347
Page 1 of 1
OffSeq TrainingCredly Certified

Lead Pen Test Professional

Technical5-day eLearningPECB Accredited
View courses