CVE-2026-98343

What it actually does

Use-after-free in dma_chan_put() and dma_release_channel() allows reading chan->device->owner after dma_device_release() has freed the dma_device and channels when the last reference is dropped.

Why it matters to the business

Potential system instability, crashes, or local privilege escalation on Linux systems performing DMA channel operations, increasing risk of denial of service or compromise in environments relying on the kernel's DMA engine.

How an attack unfolds

An attacker with local access triggers DMA channel allocation and release sequences that cause the final reference drop on the device, leading to premature freeing; subsequent reads in dma_chan_put() access freed memory, which KASAN detects as slab-use-after-free.

How to fix it

Update to a Linux kernel version containing the fix that caches the module owner in dma_chan_put() before performing the put operation; apply the patch from the dmaengine commit resolving the reference counting issue.

How to confirm the fix worked

Confirm the presence of the caching change in dma_chan_put() prior to module_put(), verify no KASAN reports on insmod or DMA channel teardown, and test with workloads that allocate and release DMA channels.

Typical attack path

1. Obtain local code execution on a Linux system
2. Load or trigger a driver/module that performs dmaengine channel get/put operations
3. Force repeated dma_chan_put and dma_release_channel calls to drop the final reference
4. Trigger the race where dma_device_release frees the structure before the trailing module_put
5. Read freed memory via chan->device->owner to achieve use-after-free

How to detect it

Review kernel logs for KASAN slab-use-after-free reports referencing dma_chan_put, inspect module load/unload sequences involving dmaengine, and search system call traces for repeated DMA channel release patterns around the time of any crashes.

What your security team should do

• Prioritize kernel updates on all Linux systems within the next maintenance window due to the 17-day-old public disclosure
• Monitor EPSS trend and watch for any increase in exploit maturity
• Restrict unprivileged module loading and DMA-capable device access where feasible
• Enable KASAN or similar memory safety tooling in test environments to validate the fix