CVE-2025-38114
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-07-03

Last updated on: 2025-11-20

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-07-03
Last Modified
2025-11-20
Generated
2026-05-07
AI Q&A
2025-07-03
EPSS Evaluated
2026-05-05
NVD
CVE-2025-38114
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.16
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-667 The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a deadlock issue in the Linux kernel's e1000 network driver. It occurs because the function e1000_down calls cancel_work_sync for the e1000 reset task while holding the RTNL lock. Meanwhile, the reset task tries to take the RTNL lock again, causing a deadlock between two CPUs. The fix involves moving the cancel_work_sync call out of e1000_down to avoid this deadlock scenario.


How can this vulnerability impact me? :

This vulnerability can cause a deadlock in the Linux kernel's network driver, potentially leading to system hangs or unresponsiveness related to network device shutdown or removal. This can impact system stability and availability.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where the e1000 driver has been fixed to move cancel_work_sync out of e1000_down and instead call it only when the device is being removed. This avoids the deadlock scenario described. There are no specific configuration changes or workarounds mentioned other than applying the patch or updated kernel that includes this fix.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart