Answer in brief
CVE-2025-39961 records a Unknown severity vulnerability in iommu/amd/pgtbl: Fix possible race while increase page table level. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=754265bcab78a9014f0f99cd35e0d610fcd7dfa7 <075abf0b1a958acfbea2435003d228e738e90346 || >=754265bcab78a9014f0f99cd35e0d610fcd7dfa7 <cd92c8ab336c3a633d46e6f35ebcd3509ae7db3b || >=754265bcab78a9014f0f99cd35e0d610fcd7dfa7 <7d462bdecb7d9c32934dab44aaeb7ea7d73a27a2 || >=754265bcab78a9014f0f99cd35e0d610fcd7dfa7 <1e56310b40fd2e7e0b9493da9ff488af145bdd0c || 6fb92f18555a7b8e085267d513612dc0ff9a5360 || b15bf74405faa1a65025eb8a6eb337e140e5250a || 0d50f7b1e8c80a8c20db5049e269468c059b0378 || 785ca708a908b9c596ede852470ba28b8dc3e40b || >=4.9.194 <4.10 || >=4.14.146 <4.15 || >=4.19.75 <4.20 || >=5.2.17 <5.3 | 075abf0b1a958acfbea2435003d228e738e90346, cd92c8ab336c3a633d46e6f35ebcd3509ae7db3b, 7d462bdecb7d9c32934dab44aaeb7ea7d73a27a2, 1e56310b40fd2e7e0b9493da9ff488af145bdd0c, 4.10, 4.15, 4.20, 5.3 |
| Linux/Linuxgeneric | 5.3 | Not reported |
Published upstream
Oct 9, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: iommu/amd/pgtbl: Fix possible race while increase page table level The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations. The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level. But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON. CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1) Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2025-39961 records a Unknown severity vulnerability in iommu/amd/pgtbl: Fix possible race while increase page table level. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=754265bcab78a9014f0f99cd35e0d610fcd7dfa7 <075abf0b1a958acfbea2435003d228e738e90346 || >=754265bcab78a9014f0f99cd35e0d610fcd7dfa7 <cd92c8ab336c3a633d46e6f35ebcd3509ae7db3b || >=754265bcab78a9014f0f99cd35e0d610fcd7dfa7 <7d462bdecb7d9c32934dab44aaeb7ea7d73a27a2 || >=754265bcab78a9014f0f99cd35e0d610fcd7dfa7 <1e56310b40fd2e7e0b9493da9ff488af145bdd0c || 6fb92f18555a7b8e085267d513612dc0ff9a5360 || b15bf74405faa1a65025eb8a6eb337e140e5250a || 0d50f7b1e8c80a8c20db5049e269468c059b0378 || 785ca708a908b9c596ede852470ba28b8dc3e40b || >=4.9.194 <4.10 || >=4.14.146 <4.15 || >=4.19.75 <4.20 || >=5.2.17 <5.3 | 075abf0b1a958acfbea2435003d228e738e90346, cd92c8ab336c3a633d46e6f35ebcd3509ae7db3b, 7d462bdecb7d9c32934dab44aaeb7ea7d73a27a2, 1e56310b40fd2e7e0b9493da9ff488af145bdd0c, 4.10, 4.15, 4.20, 5.3 |
| Linux/Linuxgeneric | 5.3 | Not reported |
Published upstream
Oct 9, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: iommu/amd/pgtbl: Fix possible race while increase page table level The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations. The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level. But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON. CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1) Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.
Quoted source text, attributed separately from HOL analysis.