Look up another CVE · open CVE-2026-90387 in the interactive tracker
CVE-2026-90387
swiotlb: Preserve allocation virtual address for dynamic pools
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem kernel/dma. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90387 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| 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
swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phys_to_virt(). swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address from the physical start address. For atomic-pool backed allocations this stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes that address to dma_free_from_pool(), which will fail to recognize the chunk Pass the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator.
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/swiotlb.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_SWIOTLB /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, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormYnot built on i386/686
- trixieYnot built on armel/rpi
- forky, sid, bookworm · linux-6.12y
- Y
- built in where it is built at all; some flavours do not build it
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_SWIOTLB
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.16%, higher than 5.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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 |
|---|---|---|
| 6.6 | 6.6.157 | 68bf3ebd8e70 |
| 6.6 | 6.12.110 | 45507dcb0847 |
| 6.6 | 6.18.52 | 35e010317782 |
| 6.6 | 7.2.6 | c1f4d7763cdf |
| 6.6 | 7.3 | 57d29044d0f2 |
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:LAttack vector, local
- The mismatch is kernel-internal: swiotlb_init_io_tlb_pool() stored phys_to_virt(start) instead of the remapped cpu_addr from dma_alloc_from_pool(), not bytes from a protocol message. Local I/O reaches it via dma_map_page_attrs() → dma_direct_map_phys() → swiotlb_map() → swiotlb_tbl_map_single() → swiotlb_find_slots() GFP_NOWAIT transient allocation.
- AC:LAttack complexity, low
- On an ARM64 realm guest force_dma_unencrypted() is true, so every GFP_NOWAIT swiotlb_alloc_tlb() in swiotlb_find_slots() uses dma_alloc_from_pool() and CONFIG_DMA_DIRECT_REMAP makes that vaddr differ from phys_to_virt(); filling io_tlb_default_mem then unmapping is attacker-driven I/O with no race.
- PR:LPrivileges required, low
- No capability check gates dma_map_page_attrs() or swiotlb_tbl_map_single(). An unprivileged user triggers the GFP_NOWAIT transient pool by ordinary I/O, e.g. virtio-blk virtqueue_add_sgs() → virtqueue_map_page_attrs(), or sendmsg on virtio-net, which bounce through SWIOTLB_FORCE on a CCA guest.
- UI:NUser interaction, none
- The attacker’s own map/unmap I/O allocates the transient pool and later dma_direct_unmap_phys() → __swiotlb_tbl_unmap_single() → swiotlb_del_transient() → swiotlb_dyn_free() → swiotlb_free_tlb(); no victim mount or other action is required.
- S:UScope, unchanged
- pool->start remains page_to_phys(tlb), so the device still DMAs to the allocated bounce pages. The defect is swiotlb_free_tlb() passing the linear phys_to_virt address into dma_free_from_pool()/__free_pages, corrupting the guest page allocator, not an IOMMU map of foreign pages or a realm/host escape.
- C:HConfidentiality impact, high
- When dma_free_from_pool() rejects the linear address, swiotlb_free_tlb() still __free_pages()s those atomic-pool frames while gen_pool still owns them and dma_common_contiguous_remap() leaves a decrypted VM_DMA_COHERENT alias, so the pages can be reallocated with a stale kernel mapping.
- I:HIntegrity impact, high
- atomic_pool_expand() allocated one high-order compound page that gen_pool carved up; __free_pages(virt_to_page(linear_vaddr), get_order(tlb_size)) is a wrong-order or tail-page free of that block, corrupting buddy metadata and yielding an arbitrary write primitive.
- A:HAvailability impact, high
- The same __free_pages() of a compound tail page or the wrong order produces bad-page handling, VM_BUG, or an oops, and any leftover coherent remap or reused frame later panics when touched.