Look up another CVE · open CVE-2026-90388 in the interactive tracker
CVE-2026-90388
iommu/dma: Check atomic pool allocation result directly
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/iommu. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-90388 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
The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.
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/iommu/dma-iommu.c
- What this is
- IOMMU DMA-API LAYERMAINTAINERS section matched on drivers/iommu/dma-iommu.c · iommu@lists.linux.dev · Maintained
Check it on the machine
grep -w CONFIG_IOMMU_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, 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 armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le
- trixieYnot built on armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64
- forky, sidYnot built on armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64
- bookworm · linux-6.12Ynot built on armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k
- Y
- built in where it is built at all; some flavours do not build it
- Build switch
- CONFIG_IOMMU_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-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.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/iommu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.9 | 5.10.270 | ac9cd0a669b8 |
| 5.9 | 5.15.221 | db46cb9da83a |
| 5.9 | 6.1.188 | d56c3f955b21 |
| 5.9 | 6.6.157 | 06dffc966930 |
| 5.9 | 6.12.110 | a4ace31d732b |
| 5.9 | 6.18.52 | fb0b39287ba8 |
| 5.9 | 7.2.6 | 8c486293ddd0 |
| 5.9 | 7.3 | af95a0ebc0a0 |
| 5.8.6 | 0 | 0 |
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
- iommu_dma_alloc() is reached from dma_alloc_attrs() on GFP_ATOMIC dma_alloc_coherent(); local entry points are VIDIOC_STREAMON scheduling mxc_jpeg_device_run()→mxc_jpeg_alloc(), and USBDEVFS_SUBMITURB in proc_do_submiturb()→usb_submit_urb(GFP_ATOMIC)→dma_pool_alloc()→pool_alloc_page(). No remote protocol message supplies the failed allocation.
- AC:LAttack complexity, low
- The attacker drives dma_alloc_from_pool() failure by consuming the atomic gen_pool (repeated GFP_ATOMIC coherent allocs or a size larger than gen_pool_avail) then issues that ioctl; __dma_alloc_from_pool() does not store cpu_addr on failure, so a non-NULL leftover skips the old !cpu_addr check with no victim-side race.
- PR:LPrivileges required, low
- mxc_jpeg_open() and proc_do_submiturb() have no capable() check; an unprivileged local user who can open the JPEG /dev/videoN or a usbfs device node reaches iommu_dma_alloc() without init-namespace root.
- UI:NUser interaction, none
- The attacker itself issues VIDIOC_QBUF/VIDIOC_STREAMON on its video fd or USBDEVFS_SUBMITURB on its usbfs fd; no separate user must mount, confirm, or plug a device.
- S:UScope, unchanged
- The leftover cpu_addr is used as a host kernel VA and page_to_phys(NULL) is mapped only in this device's iommu_dma domain via __iommu_dma_map(); that is in-kernel corruption, not a KVM/Xen escape or an extra translation into another VM's memory.
- C:HConfidentiality impact, high
- iommu_dma_alloc() returns the uninitialized cpu_addr as the coherent buffer; later loads of that object (mxc_jpeg_config_dec_desc()/print_descriptor_info on slot_data.desc, or USB TD completion from a dma_pool block carved out of the wild page) disclose kernel memory through the leftover pointer.
- I:HIntegrity impact, high
- Callers store through that pointer: mxc_jpeg_config_dec_desc() writes desc->imgsize/stm_ctrl into jpeg->slot_data.desc, and pool_initialise_page() writes dma_block.next_block into page->vaddr from the failed dma_alloc_from_pool(), a kernel write primitive.
- A:HAvailability impact, high
- page_to_phys(NULL) followed by iommu_map() in __iommu_dma_map(), or a store/load through an unmapped leftover cpu_addr in mxc_jpeg_config_dec_desc() or pool_initialise_page(), oopses or panics the kernel.