CVE-2025-39961: linux kernel — Fix

Description

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.

Is your site exposed to CVE-2025-39961?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

4.7

MEDIUM

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

Weakness Type (CWE)

CWE-362 CWE-362

Affected Products

Vendor	Product	Versions
linux	linux_kernel	4.9.194 — 4.10
linux	linux_kernel	4.14.146 — 4.15
linux	linux_kernel	4.19.75 — 4.20
linux	linux_kernel	5.2.17 — 5.3
linux	linux_kernel	5.3.1 — 6.6.108
linux	linux_kernel	6.7 — 6.12.49
linux	linux_kernel	6.13 — 6.16.9
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All

References

Advisories & Patches

https://git.kernel.org/stable/c/075abf0b1a958acfbea2435003d228e738e90346 https://git.kernel.org/stable/c/1e56310b40fd2e7e0b9493da9ff488af145bdd0c https://git.kernel.org/stable/c/7d462bdecb7d9c32934dab44aaeb7ea7d73a27a2 https://git.kernel.org/stable/c/cd92c8ab336c3a633d46e6f35ebcd3509ae7db3b

Frequently Asked Questions

What is CVE-2025-39961? +

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. It has a CVSS v3.1 base score of 4.7 (MEDIUM).

How severe is CVE-2025-39961? +

CVE-2025-39961 has a CVSS v3.1 score of 4.7 out of 10, rated MEDIUM. This is a medium-severity vulnerability that should be remediated as part of regular maintenance.

What products are affected by CVE-2025-39961? +

CVE-2025-39961 affects products from linux, specifically: linux_kernel. Check the affected products table above for specific version ranges.

How do I check if I'm vulnerable to CVE-2025-39961? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2026-41458

OwnTone Server versions 28.4 through 29.0 contain a race condition vulnerability in the DAAP login handler that allows unauthenticated attackers …

CVE-2025-13036

An authentication bypass security issue exists within FactoryTalk Historian Site Edition. By continually sending requests to the login endpoint, an …

CVE-2025-0372

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in HYPR Passwordless on Windows allows Privilege Escalation.This issue …

CVE-2025-59052

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Angular uses a …

CVE-2024-47534

go-tuf is a Go implementation of The Update Framework (TUF). The go-tuf client inconsistently traces the delegations. For example, if …

CVE-2025-64118

node-tar is a Tar for Node.js. In 7.5.1, using .t (aka .list) with { sync: true } to read tar …

CVE-2025-39961