CVE-2026-89995 PUBLISHED

dma-direct: return struct page from dma_direct_alloc_from_pool()

Assigner: Linux
Reserved: 11.09.2026 Published: 16.09.2026 Updated: 16.09.2026

In the Linux kernel, the following vulnerability has been resolved:

dma-direct: return struct page from dma_direct_alloc_from_pool()

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.

Metrics

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 8.8

AV:A - 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:L - 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:N - 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:N - 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:U - 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:H - 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:H - 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:H - 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.

Product Status

Vendor Linux
Product Linux
Versions Default: unaffected
  • affected from 5b138c534fda57c2ebc1e6de72578aa1d70788a6 to c3fdb94da43ff23287f85664174c45c45e881a3f (excl.)
  • affected from 5b138c534fda57c2ebc1e6de72578aa1d70788a6 to 408ff2d5bf555bd3f4c84a2edb95c0690bf9edc8 (excl.)
  • affected from 5b138c534fda57c2ebc1e6de72578aa1d70788a6 to feeb2ef775081a6c188cdd10e7a45369a07ce531 (excl.)
  • affected from 5b138c534fda57c2ebc1e6de72578aa1d70788a6 to 94a04ad732c9f8b9554270fc4038a06737de5c22 (excl.)
Vendor Linux
Product Linux
Versions Default: affected
  • Version 5.10 is affected
  • unaffected from 0 to 5.10 (excl.)
  • unaffected from 6.12.110 to 6.12.* (incl.)
  • unaffected from 6.18.51 to 6.18.* (incl.)
  • unaffected from 7.2.5 to 7.2.* (incl.)
  • unaffected from 7.3-rc1 to * (incl.)

References