CVE-2025-38084

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