{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-39961", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-39961" ], "published": "2025-10-09T12:15:19Z", "summary": "iommu/amd/pgtbl: Fix possible race while increase page table level", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd/pgtbl: Fix possible race while increase page table level\n\nThe AMD IOMMU host page table implementation supports dynamic page table levels\n(up to 6 levels), starting with a 3-level configuration that expands based on\nIOVA address. The kernel maintains a root pointer and current page table level\nto enable proper page table walks in alloc_pte()/fetch_pte() operations.\n\nThe IOMMU IOVA allocator initially starts with 32-bit address and onces its\nexhuasted it switches to 64-bit address (max address is determined based\non IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU\ndriver increases page table level.\n\nBut in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads\npgtable->[root/mode] without lock. So its possible that in exteme corner case,\nwhen increase_address_space() is updating pgtable->[root/mode], fetch_pte()\nreads wrong page table level (pgtable->mode). It does compare the value with\nlevel encoded in page table and returns NULL. This will result is\niommu_unmap ops to fail and upper layer may retry/log WARN_ON.\n\nCPU 0 CPU 1\n------ ------\nmap pages unmap pages\nalloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte()\n pgtable->root = pte (new root value)\n READ pgtable->[mode/root]\n\t\t\t\t\t Reads new root, old mode\n Updates mode (pgtable->mode += 1)\n\nSince Page table level updates are infrequent and already synchronized with a\nspinlock, implement seqcount to enable lock-free read operations on the read path.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": null, "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-39961" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/075abf0b1a958acfbea2435003d228e738e90346" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/cd92c8ab336c3a633d46e6f35ebcd3509ae7db3b" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7d462bdecb7d9c32934dab44aaeb7ea7d73a27a2" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/1e56310b40fd2e7e0b9493da9ff488af145bdd0c" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T12:19:11Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 8.8, "cvss_v3_severity": "High", "scenario": "AV:L - The race is reached through local DMA-mapping activity \u2014 either VFIO/iommufd map/unmap ioctls or ordinary syscall-driven I/O that exercises dma_map/dma_unmap on a device behind the AMD IOMMU. No network protocol handler processes remote data on this path.\nAC:L - The attacker controls both sides of the race: one thread issues a high-IOVA map that forces increase_address_space() while other threads issue concurrent unmaps on the same domain, and the attempt can be repeated indefinitely because each newly created protection_domain restarts at PAGE_MODE_3_LEVEL. No condition depends on state outside the attacker's influence, and CONFIG_AMD_IOMMU with v1 host page tables is the default on all AMD x86_64 systems.\nPR:L - An unprivileged local user can drive the concurrent map/unmap traffic that exhausts the 32-bit IOVA space and triggers the page-table level increase; in device-assignment deployments the VFIO/iommufd ioctl path is exercised by an unprivileged QEMU process. No root or capability in the init namespace is required.\nUI:N - The race is triggered entirely by the attacker's own concurrent DMA map/unmap operations. No victim action is needed.\nS:C - A silently-failed iommu_v1_unmap_pages() leaves a live IOMMU translation after __iommu_dma_unmap() frees the IOVA and the driver recycles the buffer, so a DMA-capable device \u2014 including a guest-controlled assigned device \u2014 retains read/write access to host physical memory it must no longer reach. This is an IOMMU/DMA containment bypass that crosses out of the kernel's own security authority.\nC:H - The stale mapping lets the device read physical pages that have been returned to the allocator and refilled with arbitrary kernel or other-tenant data, giving an unbounded read primitive over reused memory; the torn read in alloc_pte() can additionally alias a mapping onto another buffer in the domain.\nI:H - The same stale or mis-installed translation is writable, so the device can DMA arbitrary attacker-chosen data into freed-and-reused kernel memory, yielding a write primitive suitable for control-flow hijacking. The corruption is invisible to the kernel because the unmap was reported as complete.\nA:H - The failed unmap immediately produces WARN_ON splats in __iommu_dma_unmap()/iommu_unmap_nofail() (a panic with panic_on_warn), and the resulting DMA into recycled memory or the mis-built page-table subtree causes IO page faults, page-table page leaks, and kernel crashes." } } }