Look up another CVE · open CVE-2026-89804 in the interactive tracker
CVE-2026-89804
drm/nouveau/dmem: fix mismatched DMA unmap size for large folios
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: unimportant.
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-89804 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 | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| 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. |
The vulnerability
What the bug is
Device-private THP migration maps migration buffers with page_size() and records that length in dma_info->size. For a compound folio page_size() is PAGE_SIZE << order, but two teardown sites still pass a literal PAGE_SIZE to dma_unmap_page(): - nouveau_dmem_migrate_to_ram() on the success path, and - nouveau_dmem_migrate_copy_one() on the copy-error path. For an order > 0 folio this unmaps less than was mapped, leaking the remainder of the IOMMU/IOVA mapping. The other unmap sites, in nouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(), already use the saved size; use it here too.
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/gpu/drm/nouveau/nouveau_dmem.c
- What this is
- DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUSMAINTAINERS section matched on drivers/gpu/drm/nouveau/ · dri-devel@lists.freedesktop.org · Supported
- Kernel module
- none to look for. The file would have gone into nouveau, and Debian does not compile it into that module, so finding nouveau in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_DRM_NOUVEAU|CONFIG_DRM_NOUVEAU_SVM' /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 4 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, sidn
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_DRM_NOUVEAU, CONFIG_DRM_NOUVEAU_SVM
- 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-16 (33 days ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.19 | 7.2.5 | 4deb29b9d33b |
| 6.19 | 7.3 | caa1bc2a0a6c |
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
- An unprivileged local process reaches the bug via DRM render-node ioctls DRM_IOCTL_NOUVEAU_SVM_INIT and DRM_IOCTL_NOUVEAU_SVM_BIND (DRM_RENDER_ALLOW), then a CPU fault on the migrated device-private THP in nouveau_dmem_migrate_to_ram(). There is no network, Bluetooth, or USB packet path.
- AC:LAttack complexity, low
- The attacker fully controls the sequence: mmap a THP (MADV_HUGEPAGE), SVM_BIND migrate to GPU VRAM, then load/store that range to force migrate_to_ram. For order>0 folios the success path always dma_map_page(page_size()) then dma_unmap_page(PAGE_SIZE); no race or uninfluenced layout is required.
- PR:LPrivileges required, low
- NOUVEAU_SVM_INIT and NOUVEAU_SVM_BIND are DRM_RENDER_ALLOW with no capable() or DRM-master check. An ordinary local user with typical render/video-group access to /dev/dri/renderD* on a Pascal nouveau system can open the render node and issue the ioctls without init-namespace root.
- UI:NUser interaction, none
- The attacker opens the render node, initializes SVM, migrates their own anonymous THP to VRAM, and faults it back entirely in their process. No separate victim action such as mounting a filesystem or opening a crafted file is required.
- S:CScope, changed
- dma_unmap_page(PAGE_SIZE) after a compound-folio dma_map_page() leaves leftover IOMMU PTEs and returns only the start IOVA to the rcache while the original 2MB IOVA node remains. A later rcache flush can free that whole range with stale PTEs still aimed at recycled host pages, which is an IOMMU/DMA isolation bypass.
- C:HConfidentiality impact, high
- Stale IOMMU mappings keep the GPU able to DMA-read physical pages after the destination folio is freed and reused by the kernel or other processes. Combined with IOVA double-allocation of the start pfn, that is an arbitrary physical-memory read, not a bounded kernel-pointer leak.
- I:HIntegrity impact, high
- The same leftover PTEs and overlapping IOVA reuse let the NVIDIA copy engine DMA-write into recycled pages (kernel objects, other processes, or later DMA buffers). That is an arbitrary physical write through the IOMMU, exploitable for control-flow hijack, not a limited integrity change.
- A:HAvailability impact, high
- Repeated THP migrate/fault cycles leak IOVA until GPU DMA fails, and DMA into recycled pages or IOVA allocator corruption (rcache flush dropping the whole 2MB node while PTEs linger) causes kernel oops, panic, or hang, not mere performance degradation.