CVE-2025-38369
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-07-25

Last updated on: 2025-11-18

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using Running IDXD workloads in a container with the /dev directory mounted can trigger a call trace or even a kernel panic when the parent process of the container is terminated. This issue occurs because, under certain configurations, Docker does not properly propagate the mount replica back to the original mount point. In this case, when the user driver detaches, the WQ is destroyed but it still calls destroy_workqueue() attempting to completes all pending work. It's necessary to check wq->wq and skip the drain if it no longer exists.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-07-25
Last Modified
2025-11-18
Generated
2026-05-07
AI Q&A
2025-07-25
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
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-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's dmaengine idxd driver occurs when running IDXD workloads inside a container with the /dev directory mounted. If the parent process of the container terminates, it can cause a call trace or kernel panic. The root cause is that Docker does not properly propagate the mount replica back to the original mount point under certain configurations. When the user driver detaches, the workqueue (WQ) is destroyed but the code still calls destroy_workqueue() to complete pending work without checking if the workqueue still exists, leading to the issue.


How can this vulnerability impact me? :

This vulnerability can cause instability in systems running IDXD workloads in containers by triggering kernel panics or call traces when the container's parent process terminates. This can lead to system crashes or unexpected downtime, affecting availability and reliability of services running on affected Linux systems.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, avoid running IDXD workloads in containers with the /dev directory mounted until the Linux kernel is updated with the fix that checks the availability of the workqueue before using it. Applying the latest kernel update that includes this fix is recommended to prevent kernel panic or call trace issues related to this vulnerability.


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