Look up another CVE · open CVE-2026-93170 in the interactive tracker
CVE-2026-93170
dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/dma. Debian urgency: not yet assigned.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-93170 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/dma/xilinx/xilinx_dma.c
- What this is
- DMA GENERIC OFFLOAD ENGINE SUBSYSTEMMAINTAINERS section matched on drivers/dma/ · dmaengine@vger.kernel.org · Maintained
- Kernel module
- none to look for. The file would have gone into xilinx_dma, and Debian does not compile it into that module, so finding xilinx_dma in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_DMADEVICES|CONFIG_XILINX_DMA' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code. In 5 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12n
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_DMADEVICES, CONFIG_XILINX_DMA
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/dma
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.7 | 5.10.270 | 7f4b989d7d87 |
| 4.7 | 5.15.221 | 5459e02707b2 |
| 4.7 | 6.1.188 | 425630e9eea1 |
| 4.7 | 6.6.157 | fdaf297ab275 |
| 4.7 | 6.12.110 | c27d16fd2358 |
| 4.7 | 6.18.52 | ec927657524b |
| 4.7 | 7.2.6 | c3e943490ced |
| 4.7 | 7.3 | 0b6d055edb55 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is in xilinx_dma_irq_handler() and xilinx_mcdma_irq_handler(), installed via request_irq() and invoked on AXI DMA IOC/delay status in DMASR (or MCDMA CHAN_SR). Those handlers operate on locally built BD lists after dmaengine_submit() from clients such as axienet_start_xmit_dmaengine()/axienet_rx_submit_desc(); they do not parse a remote protocol field.
- AC:LAttack complexity, low
- xilinx_dma_complete_descriptor() breaks at the first AXIDMA SG BD lacking XILINX_DMA_BD_COMP_MASK, so a FRM_CNT_IRQ/DLY_CNT_IRQ mid-batch leaves active_list non-empty and the old code always sets chan->idle and calls start_transfer(). An attacker who floods submits (axienet TX, or desc_pendingcount > XILINX_DMA_COALESCE_MAX leaving stale coalesce) creates that mid-batch IRQ deterministically.
- PR:LPrivileges required, low
- An unprivileged local user reaches the AXIDMA submit path without CAP_SYS_ADMIN: sending frames on an axienet interface (axienet_start_xmit_dmaengine → dmaengine_submit/issue_pending) or using an IIO dmaengine buffer. The kernel driver, not the user, calls dma_request_chan().
- UI:NUser interaction, none
- The attacker generates the multi-descriptor load and the completion IRQs themselves (their own packets or buffer I/O). No second user must mount media, open a victim file, or change configuration.
- S:UScope, unchanged
- chan->idle, active_list, and the pre-linked seg_v BD pool are kernel dmaengine state. A spurious CURDESC/TAILDESC update corrupts those kernel buffers and client SKBs/pages under the same kernel authority; it is not a VM, IOMMU, or sandbox escape.
- C:HConfidentiality impact, high
- xilinx_dma_start_transfer() writes TAILDESC while remaining active_list BDs are still in flight. alloc_chan_resources() pre-links seg_v into a 512-entry circular next_desc ring, so the engine can walk into BDs already moved to done_list and recycled by xilinx_dma_chan_desc_cleanup(), DMA-reading leftover SKB/kernel pages.
- I:HIntegrity impact, high
- The same premature start_transfer() plus circular next_desc walk lets MM2S/S2MM continue through BDs that xilinx_dma_clean_hw_desc() zeroed or that the tasklet reused for a new transfer, so the engine DMA-writes into freed or wrong buffers — kernel memory corruption and a control-flow hijack primitive.
- A:HAvailability impact, high
- Setting chan->idle and calling start_transfer() while active_list still holds uncompleted AXIDMA BDs causes missed completions, SG decode/halt errors (chan->err in xilinx_dma_start()), and DMA into recycled descriptors that oops or permanently stall the channel.