Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Local GPU migration path (AV:L), needs order>0 THP folios on a specific teardown path (AC:H), local user privilege (PR:L); impact is a gradual IOMMU/IOVA leak → availability-low, no confirmed C/I and no scope change.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
6DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dmem: fix mismatched DMA unmap size for large folios
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.
AnalysisAI
A mismatched DMA unmap size in the nouveau DRM driver's device-private memory (dmem) migration path causes the kernel to unmap only PAGE_SIZE instead of the full compound-folio mapping size when device-private transparent huge pages (THP) are migrated. On affected systems running the open-source nouveau driver with dmem THP migration in use, an authenticated local attacker able to drive GPU device-memory migration workloads can repeatedly trigger the nouveau_dmem_migrate_to_ram() success path or the nouveau_dmem_migrate_copy_one() copy-error path, gradually leaking residual IOMMU/IOVA mappings for order>0 folios. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires the open-source nouveau DRM driver (cpe:2.3:a:linux:linux) with device-private memory (dmem) THP migration in use, and the leak only manifests for compound/large folios where order>0 (page_size() = PAGE_SIZE << order), so PAGE_SIZE-only unmaps under-cover the mapping. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The vendor CVSS of 8.8 with vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H is wildly over-scored for what the description actually describes: a mismatched DMA unmap size in the nouveau device-memory (dmem) migration path. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Apply the vendor-released kernel fixes: upgrade to Linux 7.2.5 or 7.3-rc2 (or a distribution kernel that includes upstream commits caa1bc2a0a6ca19dcb90bbf88208b0fe2decd66f and 4deb29b9d33bfdb3de4d2d9944947ecf77221e42), which make the nouveau_dmem_migrate_to_ram() success path and the nouveau_dmem_migrate_copy_one() error path unmap using the recorded dma_info->size instead of a literal PAGE_SIZE - matching the already-correct teardown logic in nouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory Linux endpoints, servers, and cloud GPU instances whose active graphics driver is nouveau and that have device-private memory (dmem) transparent huge page migration in use, and record their current kernel versions; confirm which of those hosts are multi-tenant or shared. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-80404
GHSA-f67x-82w6-7jjx