CVE-2026-93042
High · 8.8CVSS
8.8
EPSS
0.4%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A bug in the way the operating system stops data transfers can let attackers crash the system or run their own code with high privileges.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The dw-edma DMA driver calls vchan_cookie_complete() on termination, scheduling callbacks for descriptors after dmaengine_terminate_sync() and leaving issued descriptors queued; this enables use-after-free when client state is freed before late callbacks run or when terminated descriptors restart into reused buffers.
Why it matters to the business
Systems using the dw-edma DMA controller face elevated risk of kernel crashes, memory corruption, or local privilege escalation that can disrupt storage, networking, or other DMA-dependent services until the kernel is updated.
How an attack unfolds
An attacker with local access triggers DMA termination (via device reset or driver unload) while a client has pending descriptors; the late callback or restarted descriptor then dereferences already-freed client memory, leading to a use-after-free that can be leveraged for arbitrary code execution or denial of service.
How to fix it
Update the Linux kernel to a version containing the fix that moves all descriptors to the terminated list, completes cookies without callbacks, and ensures device_synchronize() waits for pending STOP operations.
How to confirm the fix worked
Confirm the kernel version includes the referenced commit; test that dmaengine_terminate_sync() no longer schedules callbacks and that device_synchronize() properly waits for pending STOPs before freeing resources.
Typical attack path
- Obtain local code execution on a system using dw-edma hardware
- Issue DMA transfers through a client driver
- Force termination of the channel (e.g., via device removal or explicit terminate)
- Trigger the pending STOP interrupt or reuse freed buffers
- Execute code via the resulting use-after-free or cause kernel panic
How to detect it
Review kernel logs for oops or warnings mentioning vchan_cookie_complete after dmaengine_terminate_sync calls, and inspect crash dumps for use-after-free patterns involving dw-edma or virt-dma descriptors.
What your security team should do
- Prioritize kernel updates on all systems exposing dw-edma hardware within the next 30 days
- Restrict local user access on affected hosts until patched
- Monitor for kernel oops or panic logs related to vchan or dw-edma after termination calls
The record
In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Terminate all descriptors without callbacks The DMA Engine client documentation says in the "Terminate APIs" section of Documentation/driver-api/dmaengine/client.rst: "No callback functions will be called for any incomplete transfers." dw-edma instead calls vchan_cookie_complete() when a deferred STOP reaches the interrupt handler. This schedules a callback for the active descriptor and leaves other issued or submitted descriptors queued. A late callback after dmaengine_terminate_sync() can dereference client state that has already been freed, while leftover descriptors may later restart into reused buffers or leak. Move all issued and submitted descriptors to the terminated list whenever termination completes. For a pending STOP, do this from both the DONE and ABORT paths. Complete their cookies in order without scheduling callbacks. A STOP can remain pending until the running transfer raises an interrupt. Make device_synchronize() wait for such a pending STOP to complete before releasing terminated descriptors. Reuse it from free_chan_resources(), then release the remaining virt-dma resources. Sleep instead of busy-polling while waiting, and warn if the existing timeout expires.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|