FlawAtlas
Search the atlas
CVE-2025-38085 Not scored

mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.

Exploit probability 0.1%
Published June 28, 2025
Required by Not available
Last source change July 15, 2026

02 / AFFECTED SOFTWARE

Affected packages

Linux Kernel
Unknown Unknown

03 / CONNECTIONS

Connected vulnerabilities

related ALSA-2025:13589
related ALSA-2025:13590
related ALSA-2025:13962
related OPENSUSE-SU-2025:20172-1
related SUSE-SU-2025:02853-1
related SUSE-SU-2025:02923-1
related SUSE-SU-2025:02969-1
related SUSE-SU-2025:02996-1
related SUSE-SU-2025:02997-1
related SUSE-SU-2025:03011-1
related SUSE-SU-2025:03023-1
related SUSE-SU-2025:03628-1
related SUSE-SU-2025:20577-1
related SUSE-SU-2025:20586-1
related SUSE-SU-2025:20601-1
related SUSE-SU-2025:20602-1
related SUSE-SU-2025:3716-1
related SUSE-SU-2025:4149-1
related SUSE-SU-2025:4320-1
related SUSE-SU-2026:0316-1
related SUSE-SU-2026:20012-1
related SUSE-SU-2026:20015-1
related SUSE-SU-2026:20021-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities CVE-2025-38085

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.

View original source

05 / REFERENCES

Further evidence