{"api_version":"1","generated_at":"2026-09-17T06:06:34+00:00","cve":"CVE-2026-89804","urls":{"html":"https://cve.report/CVE-2026-89804","api":"https://cve.report/api/cve/CVE-2026-89804.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-89804","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-89804"},"summary":{"title":"drm/nouveau/dmem: fix mismatched DMA unmap size for large folios","description":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/dmem: fix mismatched DMA unmap size for large folios\n\nDevice-private THP migration maps migration buffers with page_size()\nand records that length in dma_info->size.  For a compound folio\npage_size() is PAGE_SIZE << order, but two teardown sites still pass a\nliteral PAGE_SIZE to dma_unmap_page():\n\n  - nouveau_dmem_migrate_to_ram() on the success path, and\n  - nouveau_dmem_migrate_copy_one() on the copy-error path.\n\nFor an order > 0 folio this unmaps less than was mapped, leaking the\nremainder of the IOMMU/IOVA mapping.  The other unmap sites, in\nnouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(), already\nuse the saved size; use it here too.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-16 11:16:45","updated_at":"2026-09-16 15:18:10"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"8.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","baseScore":8.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"CHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"8.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","data":{"baseScore":8.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/caa1bc2a0a6ca19dcb90bbf88208b0fe2decd66f","name":"https://git.kernel.org/stable/c/caa1bc2a0a6ca19dcb90bbf88208b0fe2decd66f","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/4deb29b9d33bfdb3de4d2d9944947ecf77221e42","name":"https://git.kernel.org/stable/c/4deb29b9d33bfdb3de4d2d9944947ecf77221e42","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-89804","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89804","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected c3228747107705d47c7e9a03598a434a0380cb73 4deb29b9d33bfdb3de4d2d9944947ecf77221e42 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected c3228747107705d47c7e9a03598a434a0380cb73 caa1bc2a0a6ca19dcb90bbf88208b0fe2decd66f git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.19","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.19 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.5 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc2 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["drivers/gpu/drm/nouveau/nouveau_dmem.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"4deb29b9d33bfdb3de4d2d9944947ecf77221e42","status":"affected","version":"c3228747107705d47c7e9a03598a434a0380cb73","versionType":"git"},{"lessThan":"caa1bc2a0a6ca19dcb90bbf88208b0fe2decd66f","status":"affected","version":"c3228747107705d47c7e9a03598a434a0380cb73","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["drivers/gpu/drm/nouveau/nouveau_dmem.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.19"},{"lessThan":"6.19","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.5","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc2","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.5","versionStartIncluding":"6.19","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc2","versionStartIncluding":"6.19","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/dmem: fix mismatched DMA unmap size for large folios\n\nDevice-private THP migration maps migration buffers with page_size()\nand records that length in dma_info->size.  For a compound folio\npage_size() is PAGE_SIZE << order, but two teardown sites still pass a\nliteral PAGE_SIZE to dma_unmap_page():\n\n  - nouveau_dmem_migrate_to_ram() on the success path, and\n  - nouveau_dmem_migrate_copy_one() on the copy-error path.\n\nFor an order > 0 folio this unmaps less than was mapped, leaking the\nremainder of the IOMMU/IOVA mapping.  The other unmap sites, in\nnouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(), already\nuse the saved size; use it here too."}],"metrics":[{"cvssV3_1":{"baseScore":8.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","version":"3.1"},"scenarios":[{"lang":"en","value":"AV:L - 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.\nAC:L - 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.\nPR:L - 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.\nUI:N - 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.\nS:C - 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.\nC:H - 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.\nI:H - 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.\nA:H - 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."}]}],"providerMetadata":{"dateUpdated":"2026-09-16T14:38:49.967Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/4deb29b9d33bfdb3de4d2d9944947ecf77221e42"},{"url":"https://git.kernel.org/stable/c/caa1bc2a0a6ca19dcb90bbf88208b0fe2decd66f"}],"title":"drm/nouveau/dmem: fix mismatched DMA unmap size for large folios","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-89804","datePublished":"2026-09-16T10:30:37.638Z","dateReserved":"2026-09-11T19:38:34.767Z","dateUpdated":"2026-09-16T14:38:49.967Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-16 11:16:45","lastModifiedDate":"2026-09-16 15:18:10","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","baseScore":8.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"CHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":2,"impactScore":6}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"89804","Ordinal":"1","Title":"drm/nouveau/dmem: fix mismatched DMA unmap size for large folios","CVE":"CVE-2026-89804","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"89804","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/dmem: fix mismatched DMA unmap size for large folios\n\nDevice-private THP migration maps migration buffers with page_size()\nand records that length in dma_info->size.  For a compound folio\npage_size() is PAGE_SIZE << order, but two teardown sites still pass a\nliteral PAGE_SIZE to dma_unmap_page():\n\n  - nouveau_dmem_migrate_to_ram() on the success path, and\n  - nouveau_dmem_migrate_copy_one() on the copy-error path.\n\nFor an order > 0 folio this unmaps less than was mapped, leaking the\nremainder of the IOMMU/IOVA mapping.  The other unmap sites, in\nnouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(), already\nuse the saved size; use it here too.","Type":"Description","Title":"drm/nouveau/dmem: fix mismatched DMA unmap size for large folios"}]}}}