EUVD-2026-35408
GHSA-rq5m-62rx-j536
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Local-only attack via mmap syscall with standard user privileges; only availability impact through kernel resource exhaustion, no confidentiality or integrity effect.
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
5DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
Revert "mm/hugetlbfs: update hugetlbfs to use mmap_prepare"
This reverts commit ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use mmap_prepare") with conflict resolution to account for changes in commit ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use mmap_prepare").
The patch incorrectly handled hugetlb VMA lock allocation at the mmap_prepare stage, where a failed allocation occurring after mmap_prepare is called might result in the lock leaking.
There is no risk of a merge causing a similar issues, as VMA_DONTEXPAND_BIT is set for hugetlb mappings.
As a first step in addressing this issue, simply revert the change so we can rework how we do this having corrected the underlying issues.
We maintain the VMA flags changes as best we can, accounting for the fact that we were working with a VMA descriptor previously and propagating like-for-like changes for this.
Note that we invoke vma_set_flags() and do not call vma_start_write() as vm_flags_set() does. This is OK as it's being done in an .mmap hook where the VMA is not yet linked into the tree so nobody else can be accessing it.
AnalysisAI
Lock resource leak in Linux kernel hugetlbfs subsystem enables local denial of service against systems using huge page memory mappings. Introduced by a faulty commit (ea52cb24cd3f) that incorrectly handled VMA lock allocation during the mmap_prepare stage, the defect allows a failed post-mmap_prepare allocation to leave a VMA lock unreleased, leaking kernel resources. This CVE documents the corrective revert; systems running affected kernel versions (around 6.19 through pre-7.0.12 and pre-7.1-rc6) with hugetlbfs in use are exposed to potential availability impact. No public exploit code exists and EPSS probability is 0.02% (5th percentile), indicating very low real-world exploitation activity.
Technical ContextAI
The hugetlbfs subsystem provides Linux kernel support for large memory pages (hugepages), commonly used in high-performance workloads such as databases and HPC. VMA (Virtual Memory Area) descriptors track process memory regions in the kernel's mm subsystem. The mmap_prepare hook, introduced for cleaner pre-mapping logic, was incorrectly used to allocate VMA locks for hugetlb mappings. If that allocation fails at the mmap_prepare stage - before the VMA is fully linked into the red-black tree - the lock can be left dangling and never freed. The fix reverts to the prior approach while preserving VMA flag changes; the vma_set_flags() call is used instead of vm_flags_set() because at .mmap hook time the VMA is not yet tree-linked, making concurrent access impossible and the explicit vma_start_write() call unnecessary. CWE classification was not assigned by NVD, but the root cause class is resource management error (akin to CWE-401, missing release of memory after effective lifetime). CPE cpe:2.3:a:linux:linux identifies the upstream Linux kernel as the affected product.
RemediationAI
The primary fix is upgrading to Linux kernel 7.0.12 or 7.1-rc6, which include the revert of commit ea52cb24cd3f. Stable branch fix commits are available at https://git.kernel.org/stable/c/83f9efcce93f8574be2279090ee2aec58b86cda7 and https://git.kernel.org/stable/c/3af5fc3f0ac98c624c109c8c0796fa46e814344c. Linux distribution vendors (Red Hat, Ubuntu, SUSE, Debian) will typically backport this fix to their supported kernel versions - check respective security advisories. As a compensating control where patching is not immediately feasible, disabling hugetlbfs usage eliminates the vulnerable code path: this can be done by removing hugepages kernel parameters (hugepages=, hugepagesz=) from the bootloader configuration and ensuring no application or service is configured to use /dev/hugepages or MAP_HUGETLB. The trade-off is loss of large-page performance benefits for workloads that depend on them. NVD advisory detail is available at https://nvd.nist.gov/vuln/detail/CVE-2026-46318.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today