CVE-2026-46318

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "mm/hugetlbfs: update hugetlbfs to use mmap_prepare"<br /> <br /> This reverts commit ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use<br /> mmap_prepare") with conflict resolution to account for changes in commit<br /> ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use mmap_prepare").<br /> <br /> The patch incorrectly handled hugetlb VMA lock allocation at the<br /> mmap_prepare stage, where a failed allocation occurring after mmap_prepare<br /> is called might result in the lock leaking.<br /> <br /> There is no risk of a merge causing a similar issues, as<br /> VMA_DONTEXPAND_BIT is set for hugetlb mappings.<br /> <br /> As a first step in addressing this issue, simply revert the change so we<br /> can rework how we do this having corrected the underlying issues.<br /> <br /> We maintain the VMA flags changes as best we can, accounting for the fact<br /> that we were working with a VMA descriptor previously and propagating<br /> like-for-like changes for this.<br /> <br /> Note that we invoke vma_set_flags() and do not call vma_start_write() as<br /> vm_flags_set() does. This is OK as it&amp;#39;s being done in an .mmap hook where<br /> the VMA is not yet linked into the tree so nobody else can be accessing<br /> it.