CVE-2026-80902

What it actually does

The Allwinner sun6i DMA engine driver in the Linux kernel fails to reclaim active non-cyclic DMA descriptors and their linked-list item (LLI) chains when a transfer is terminated. Only cyclic descriptors were previously returned to the cleanup path, so aborted non-cyclic transfers permanently leak descriptor and scatter-gather memory. A missing pchan->desc != pchan->done guard can also insert an already-completed descriptor twice into vchan lists, corrupting kernel linked lists and enabling invalid pointer walks, crashes, or further kernel memory corruption in dmaengine.

Why it matters to the business

Linux devices built on Allwinner sun6i-family SoCs (common in embedded, IoT, SBC, set-top, and Android-class products) can suffer gradual kernel memory exhaustion, DMA-using subsystem failures (audio, storage, SPI, and similar), or unexpected reboots. The issue is about 25 days old, is not in CISA KEV, has no known ransomware use, and has no public exploit maturity, so mass opportunistic attacks are unlikely; residual risk is local denial of service and instability on unpatched embedded fleets that cancel DMA frequently.

How an attack unfolds

This is a local, hardware-specific kernel defect, not a network service bug. An attacker with the ability to start and then abort non-cyclic DMA on a sun6i channel—typically via a userspace-accessible device that sits on dmaengine—forces the terminate path that skips reclaim of non-cyclic descriptors and LLI chains. Repeating start/terminate cycles leaks kernel memory until allocation failures or an OOM condition. If a completed descriptor is still referenced as the active descriptor, the double-add path corrupts vchan lists, which usually panics the kernel and, in a skilled local attack, could be treated as a list-corruption primitive. No named threat actors or in-the-wild campaigns are associated with this issue.

How to fix it

Install a Linux kernel that includes the upstream dmaengine sun6i-dma fix: terminate via vchan_terminate_vdesc() so both cyclic and non-cyclic descriptors (and LLI chains) are placed on desc_terminated for cleanup, and skip re-queue when pchan->desc == pchan->done. Because no distro or package fixed versions were supplied, apply the latest vendor/BSP kernel (Android, OpenWrt, Armbian, Allwinner, Yocto, or mainline stable) that lists this DMA terminate-reclaim change, or backport that patch. There is no complete configuration workaround; reducing untrusted access to devices that abort DMA only lowers exposure.

How to confirm the fix worked

Confirm drivers/dma/sun6i-dma.c uses vchan_terminate_vdesc() on terminate and contains the pchan->desc != pchan->done guard; verify the running image’s changelog or git history includes that change. On representative Allwinner hardware, start and terminate non-cyclic DMA and watch that kmalloc/dmaengine descriptor usage and kmemleak reports do not grow without bound. Exercise audio, storage, and SPI paths after abort to ensure channels still complete. Absence of new list-corruption warnings or sun6i-dma oopses under terminate stress indicates the double-add path is closed.

Typical attack path

1. Obtain local code execution or a privileged userspace foothold on a Linux system whose DMA controller is bound to the sun6i-dma driver
2. Identify a dmaengine consumer that programs non-cyclic transfers (for example audio, MMC/SPI, or similar platform drivers)
3. Repeatedly start DMA work and terminate or abort it so the driver takes the unreclaimed non-cyclic descriptor path
4. Optionally race termination with completion so a finished descriptor is queued twice and vchan lists are corrupted
5. Drive kernel memory exhaustion or a dmaengine/list oops to deny service, or attempt to abuse list corruption for further kernel-memory influence

How to detect it

This defect does not leave network callbacks or dropped files; look for prior local abuse via kernel logs and memory-pressure artifacts. Review dmesg/journal/crash dumps around dmaengine terminate activity for sun6i-dma stack frames, vchan list corruption, LIST_POISON, and paging requests in descriptor walkers. Correlate unexplained slab growth (dmaengine/virt-dma/kmalloc descriptor caches), kmemleak records of DMA LLI or virt-dma descriptors, and OOM or device-reset events after workloads that abort DMA. Sudden storms of DMA abort ioctls or equivalent from an untrusted process, followed by kernel memory growth or a sun6i-dma oops, are the practical signs of attempted or accidental triggering. No APT-specific telemetry is known.

• sun6i-dma
• drivers/dma/sun6i-dma.c
• vchan_terminate
• list_del corruption
• LIST_POISON
• Unable to handle kernel paging request

What your security team should do

• Inventory Linux/embedded fleets for Allwinner sun6i-class SoCs and kernels that ship drivers/dma/sun6i-dma.c
• Prioritize kernel updates or backports of the sun6i-dma terminate-reclaim fix; this is not CISA KEV but should not linger on long-lived embedded images
• Restrict untrusted local access to DMA-backed device nodes until patched
• Add kernel-log monitoring for sun6i-dma and dmaengine list/oops traces during terminate-heavy workloads
• After patching, validate DMA abort paths and kernel memory stability on a canary device before broad rollout