Look up another CVE · open CVE-2026-89995 in the interactive tracker
CVE-2026-89995
dma-direct: return struct page from dma_direct_alloc_from_pool()
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem kernel/dma. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89995 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| 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
Commit 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") changed dma_direct_alloc_from_pool() to return the CPU address from dma_alloc_from_pool(). That fits dma_direct_alloc(), but dma_direct_alloc_pages() also uses the helper and expects a struct page *. Fix this by making dma_direct_alloc_from_pool() return the struct page * again, and pass the CPU address back through an out-parameter for the dma_direct_alloc() caller.
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.
kernel/dma/direct.c
- What this is
- DMA MAPPING HELPERSMAINTAINERS section matched on kernel/dma/ · iommu@lists.linux.dev · Supported
Check it on the machine
grep -w CONFIG_HAS_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 builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12y
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_HAS_DMA
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-16 (33 days ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.32%, higher than 23.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- kernel/dma
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.10 | 6.12.110 | c3fdb94da43f |
| 5.10 | 6.18.51 | 408ff2d5bf55 |
| 5.10 | 7.2.5 | feeb2ef77508 |
| 5.10 | 7.3 | 94a04ad732c9 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| 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:AAttack vector, adjacent network
- dma_direct_alloc_pages() takes the buggy pool path from dma_alloc_noncoherent(GFP_ATOMIC) in ath11k_peer_rx_tid_setup(), which runs when a same-LAN WiFi peer associates or starts a Block Ack. On SEV/TDX/CCA guests and SME hosts, force_dma_unencrypted() is true, so a wireless attacker reaches the type confusion without a wired/Internet service.
- AC:LAttack complexity, low
- The peer fully controls association and ADDBA, so the GFP_ATOMIC dma_alloc_pages() call is deterministic with no race to win. Confidential-computing dma-direct (atomic decrypted pool, no IOMMU) is the scored deployment, not an uninfluenced memory layout or rare extra config.
- PR:NPrivileges required, none
- ath11k peer/TID setup and the cdns3 gadget GFP_ATOMIC dma_alloc_noncoherent() path run in kernel interrupt/softirq context with no host account, capability, or user-namespace check. An unauthenticated WiFi peer (or USB gadget host) is sufficient.
- UI:NUser interaction, none
- Peer creation and Block Ack setup are 802.11 protocol operations. Once the interface is up as an AP/hotspot or an already-associated STA, exploitation needs no victim mount, open, or other interactive step.
- S:UScope, unchanged
- The allocator returns a CPU virtual address as a struct page *, corrupting page and DMA bookkeeping in the same kernel. This is not a VM escape, IOMMU bypass, or host/guest confidential-computing boundary crossing.
- C:HConfidentiality impact, high
- Callers treat the kernel VA as a struct page, so page_to_virt/page_address/page_to_pfn compute wrong addresses and dma_mmap_pages() can remap a bogus PFN into userspace. That type confusion is an arbitrary kernel-memory disclosure primitive.
- I:HIntegrity impact, high
- sg_set_page, page_address stores, dma_set_encrypted(), and dma_free_contiguous() then operate on the fake page pointer, writing, re-encrypting, or freeing the wrong memory. That is an arbitrary kernel write/free primitive usable for control-flow hijack.
- A:HAvailability impact, high
- Interpreting a DMA pool virtual address as a struct page * causes invalid vmemmap/page-flag accesses and buddy frees, which oops or panic the kernel even when not fully turned into a stable read/write primitive.