Cloudanix VulnDB

CVE-2026-93040

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel's DMA engine could let certain operations get stuck, causing data transfer features to stop working until the system is restarted or updated.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in dw-edma DMA channel state handling where pause/resume operations and interrupt handlers access request/status/configured fields without consistent locking under vc.lock, allowing stale state to wedge the channel permanently.

Why it matters to the business

DMA engine operations on affected Linux systems can become unresponsive, leading to degraded performance or failures in hardware-accelerated data transfers such as storage or networking.

How an attack unfolds

An attacker with local access triggers concurrent pause/resume calls and interrupt completions on the same channel; the resulting inconsistent state (e.g., pause request recorded after channel idles) prevents further progress because issue_pending and terminate_all cannot recover the channel.

How to fix it

Update to a Linux kernel containing the fix that acquires vc.lock around all channel state checks in pause, resume, and issue_pending; rebuild and deploy the updated kernel across all affected hosts.

How to confirm the fix worked

Verify the presence of the locking changes in the dw-edma source (vc.lock held during state reads/writes) and confirm the running kernel version includes the commit that serializes channel state access.

Typical attack path

  1. Obtain local code execution or user privileges on the target system
  2. Identify and exercise DMA channels using dw-edma driver
  3. Rapidly issue pause/resume operations while generating interrupts that complete descriptors
  4. Observe channel becoming wedged with no further DMA activity possible

How to detect it

Review kernel logs and dmesg for dw-edma channel state warnings or stalled DMA descriptors; examine call traces involving pause/resume and interrupt handlers under high concurrency.

What your security team should do

  • Prioritize kernel updates on systems using dw-edma DMA hardware
  • Test updated kernels in staging environments before broad rollout
  • Monitor for DMA-related hangs or stalled transfers as a temporary indicator of exposure

The record

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 EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() 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 packages

Ecosystem Package Introduced Fixed