CVE-2025-38114 in Linux
Summary
by MITRE • 07/03/2025
In the Linux kernel, the following vulnerability has been resolved:
e1000: Move cancel_work_sync to avoid deadlock
Previously, e1000_down called cancel_work_sync for the e1000 reset task (via e1000_down_and_stop), which takes RTNL.
As reported by users and syzbot, a deadlock is possible in the following scenario:
CPU 0: - RTNL is held - e1000_close - e1000_down - cancel_work_sync (cancel / wait for e1000_reset_task())
CPU 1: - process_one_work - e1000_reset_task - take RTNL
To remedy this, avoid calling cancel_work_sync from e1000_down (e1000_reset_task does nothing if the device is down anyway). Instead, call cancel_work_sync for e1000_reset_task when the device is being removed.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 04/17/2026
The vulnerability identified as CVE-2025-38114 represents a critical deadlock condition within the Linux kernel's e1000 network driver implementation. This issue manifests in the interaction between the network driver's reset functionality and the kernel's RTNL (Real-Time Network Lock) mechanism, creating a scenario where system threads become permanently blocked. The e1000 driver, which supports Intel's 1000 series Ethernet controllers, is affected by this flaw that can lead to complete system unresponsiveness under specific operational conditions.
The technical root cause of this vulnerability stems from improper synchronization handling within the driver's shutdown sequence. When the e1000_close function is invoked to terminate network operations, it subsequently calls e1000_down which executes cancel_work_sync against the e1000_reset_task. This operation occurs while holding the RTNL lock, creating a circular dependency that prevents the system from proceeding. The deadlock scenario emerges because the reset task itself attempts to acquire the same RTNL lock when it executes on a different CPU core, resulting in a classic mutual exclusion deadlock pattern.
From a cybersecurity perspective, this vulnerability maps directly to CWE-362, which describes concurrent execution using shared resources without proper synchronization mechanisms. The issue also aligns with ATT&CK technique T1490, specifically targeting system service denial through resource exhaustion or deadlock conditions. The flaw demonstrates how improper lock management in kernel space can create persistent availability issues that affect the entire system's operational integrity, particularly in environments where network reliability is critical.
The operational impact of this vulnerability extends beyond simple system hangs to potentially compromise network availability and system stability. In production environments, this deadlock condition can result in complete network interface unavailability, forcing administrators to perform manual system reboots to restore functionality. The vulnerability is particularly concerning in high-availability systems where network interruptions can cascade into larger service disruptions, making this a critical security concern for enterprise and cloud environments.
Mitigation strategies for CVE-2025-38114 involve implementing a modified shutdown sequence that separates the work cancellation from the RTNL lock acquisition. The fix repositions the cancel_work_sync call to occur only during device removal rather than during the normal shutdown sequence, eliminating the lock contention scenario. This approach aligns with established kernel development practices for managing workqueue operations in lock-sensitive contexts. System administrators should prioritize applying the kernel updates containing this fix, particularly in environments where network reliability is paramount. The solution also emphasizes the importance of proper lock ordering and the avoidance of nested lock acquisitions in kernel modules, serving as a valuable lesson in kernel security design principles for network driver development.