Linux kernel idxd: container with /dev mounted can panic the host when the parent process dies

Impact

Running an IDXD (Intel Data Streaming Accelerator) workload inside a container that has /dev mounted can produce a call trace or a full kernel panic when the container's parent process is terminated. Because Docker does not always propagate the mount replica back to the original mount point, the user driver detaches and the work queue is destroyed, but destroy_workqueue() is still called on it to drain pending work. That is a host-wide denial of service triggered by the lifecycle of a single container - the exact shape of problem an operator cannot tolerate on a shared accelerator node, where one tenant's container exit takes down every other job on the box and the node has to be rebooted to recover. Accelerator device files handed into containers are the standard pattern on these nodes, which is what makes the path reachable at all.

Who can reach it

Any tenant whose container is given the IDXD device through a mounted /dev, in the configurations where the mount replica is not propagated back. No authentication beyond being able to start such a container and then have its parent process terminated; no privileged capability is named in the record.

What to do

Patch to a stable kernel containing the wq->wq availability check and reboot each affected node; idxd is a module, so a module reload is theoretically enough but means taking the accelerator away from running jobs. Until then, the practical mitigation is to stop bind-mounting the whole of /dev into containers that use IDXD and to hand in only the specific device nodes. Only the upstream commits are linked; no vendor advisory with a fixed version is in the record.

References

Related entries

• Linux kernel virtio-net: unchecked received length in xdp_linearize_page allows an out-of-bounds readCVE-2025-38375 · Linux kernel virtio-net (xdp_linearize_page received-length check)High
• Linux i915 GPU kernel driver (GT timeline / VMA allocation): A timeline is left held when VMA allocation fails, soCVE-2025-38389 · Linux i915 GPU kernel driver (GT timeline / VMA allocation)High
• Linux kernel SMC (struct smc_sock type confusion with inet_sock): Struct smc_sock does not embed struct inet_sock asCVE-2025-38475 · Linux kernel SMC (struct smc_sock type confusion with inet_sock)High
• Linux kernel (net/xfrm): The guard that forbids changing a collect_md xfrm interface never fired, so a changelink putsCVE-2025-38500 · Linux kernel (net/xfrm)High
• Linux kernel perf/core: splitting a perf ring-buffer mapping leaks reference counts on the bufferCVE-2025-38563 · Linux kernel perf/core (ring-buffer and AUX mmap, missing may_split() callback)High
• Linux kernel perf/core: a failed perf_mmap() still runs event_mapped, leaking the rdpmc reference countCVE-2025-38565 · Linux kernel perf/core (perf_mmap() failure path, event_mapped callback and perf_rdpmc_allowed)High