CVE-2026-93040: dmaengine: dw-edma: Serialize channel state checks
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: dw-edma: Serialize channel state checks
pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent.
For example, pause() can observe EDMASTBUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMASTIDLE, and then record EDMAREQPAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issuepending() requires EDMAREQNONE, the channel is wedged for good: terminateall() leaves the stale request behind, so even reconfiguring the channel does not recover it.
issuepending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.
Affected Software
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel's DesignWare eDMA dmaengine driver are exposed when channel pause(), resume(), interrupt handling, or issue_pending() operations can race on the same channel state.
What conditions trigger the failure?
A race can occur when pause() observes a busy channel just before an interrupt handler completes the final descriptor and changes the channel to idle. pause() may then leave a pause request on an idle channel, with no later interrupt available to acknowledge it.
What is the operational impact once the race occurs?
The affected channel can become permanently wedged because issue_pending() requires the request state to be none. terminate_all() does not clear the stale request, so reconfiguring the channel also does not restore operation.
How can the issue be remediated?
Apply the available Linux kernel stable fixes referenced in the advisory. The fix serializes channel-state checks with vc.lock and moves the configured check in issue_pending() under that lock so configured, request, and status are evaluated together.