CVE-2025-38084: debian linux — Fix

Description

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [[email protected]: v2]

Is your site exposed to CVE-2025-38084?

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

CVSS v3.1 Score

5.5

MEDIUM

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

Affected Products

Vendor	Product	Versions
linux	linux_kernel	2.6.20 — 5.10.239
linux	linux_kernel	5.11 — 5.15.186
linux	linux_kernel	5.16 — 6.1.142
linux	linux_kernel	6.2 — 6.6.95
linux	linux_kernel	6.7 — 6.12.35
linux	linux_kernel	6.13 — 6.15.4
debian	debian_linux	All

References

Advisories & Patches

https://git.kernel.org/stable/c/081056dc00a27bccb55ccc3c6f230a3d5fd3f7e0 https://git.kernel.org/stable/c/2511ac64bc1617ca716d3ba8464e481a647c1902 https://git.kernel.org/stable/c/366298f2b04d2bf1f2f2b7078405bdf9df9bd5d0 https://git.kernel.org/stable/c/8a21d5584826f4880f45bbf8f72375f4e6c0ff2a https://git.kernel.org/stable/c/9cf5b2a3b72c23fb7b84736d5d19ee6ea718762b https://git.kernel.org/stable/c/af6cfcd0efb7f051af221c418ec8b37a10211947 https://git.kernel.org/stable/c/e8847d18cd9fff1edbb45e963d9141273c3b539c

Other References

https://project-zero.issues.chromium.org/issues/420715744 https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html

Frequently Asked Questions

What is CVE-2025-38084? +

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [[email protected]: v2] It has a CVSS v3.1 base score of 5.5 (MEDIUM).

How severe is CVE-2025-38084? +

CVE-2025-38084 has a CVSS v3.1 score of 5.5 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-38084? +

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

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

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-2025-9588 10.0

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Iron Mountain Archiving Services Inc. …

CVE-2025-57870 10.0

A SQL Injection vulnerability exists in Esri ArcGIS Server versions 11.3, 11.4 and 11.5 on Windows, Linux and Kubernetes. This …

CVE-2026-48286 10.0

Adobe Campaign Classic (ACC) versions 7.4.3 build 9396 and earlier are affected by an Incorrect Authorization vulnerability that could result …

CVE-2026-13782 10.0

Use after free in Browser in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer …

CVE-2026-48303 10.0

Adobe Campaign Classic (ACC) versions 7.4.3 build 9394 and earlier are affected by an Incorrect Authorization vulnerability that could result …

CVE-2025-34028 10.0

The Commvault Command Center Innovation Release allows an unauthenticated actor to upload ZIP files that represent install packages that, when …

CVE-2025-38084