CVE-2026-46318
Revert "mm/hugetlbfs: update hugetlbfs to use mmap_prepare"
Description
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.
INFO
Published Date :
June 9, 2026, 1:16 p.m.
Last Modified :
July 23, 2026, 8:10 a.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS 3.1 | MEDIUM | [email protected] |
Solution
- Revert the problematic "mm/hugetlbfs" commit.
- Rework hugetlb VMA lock allocation logic.
- Ensure VMA flags are correctly propagated.
- Apply the provided patch to the kernel.
Public PoC/Exploit Available at Github
CVE-2026-46318 has a 1 public
PoC/Exploit available at Github.
Go to the Public Exploits tab to see the list.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-46318.
| URL | Resource |
|---|---|
| https://git.kernel.org/stable/c/3af5fc3f0ac98c624c109c8c0796fa46e814344c | Patch |
| https://git.kernel.org/stable/c/83f9efcce93f8574be2279090ee2aec58b86cda7 | Patch |
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-46318 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-46318
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Record all the bugs discovered by DevGen
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-46318 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-46318 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Translated by [email protected]
Jul. 23, 2026
Action Type Old Value New Value Added Translation Title: el kernel de Linux, Description: En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: Revertir 'mm/hugetlbfs: update hugetlbfs to use mmap_prepare' Esto revierte el commit ea52cb24cd3f ('mm/hugetlbfs: update hugetlbfs to use mmap_prepare') con resolución de conflictos para tener en cuenta los cambios en el commit ea52cb24cd3f ('mm/hugetlbfs: update hugetlbfs to use mmap_prepare'). El parche manejó incorrectamente la asignación del bloqueo VMA de hugetlb en la etapa mmap_prepare, donde una asignación fallida que ocurre después de que se llama a mmap_prepare podría resultar en la fuga del bloqueo. No hay riesgo de que una fusión cause problemas similares, ya que VMA_DONTEXPAND_BIT está configurado para las asignaciones de hugetlb. Como primer paso para abordar este problema, simplemente revertimos el cambio para que podamos reelaborar cómo hacemos esto habiendo corregido los problemas subyacentes. Mantenemos los cambios de las banderas VMA lo mejor que podemos, teniendo en cuenta el hecho de que estábamos trabajando con un descriptor VMA anteriormente y propagando cambios equivalentes para esto. Tenga en cuenta que invocamos vma_set_flags() y no llamamos a vma_start_write() como lo hace vm_flags_set(). Esto está bien ya que se está haciendo en un gancho .mmap donde el VMA aún no está vinculado al árbol, por lo que nadie más puede acceder a él. -
Initial Analysis by [email protected]
Jul. 08, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Added CWE NVD-CWE-noinfo Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.1:rc5:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.19 up to (excluding) 7.0.12 Added Reference Type kernel.org: https://git.kernel.org/stable/c/3af5fc3f0ac98c624c109c8c0796fa46e814344c Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/83f9efcce93f8574be2279090ee2aec58b86cda7 Types: Patch -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jun. 17, 2026
Action Type Old Value New Value Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': 'ea52cb24cd3fb121283754ab82b2cb3044609359', 'lessThan': '3af5fc3f0ac98c624c109c8c0796fa46e814344c', 'versionType': 'git'}, {'status': 'affected', 'version': 'ea52cb24cd3fb121283754ab82b2cb3044609359', 'lessThan': '83f9efcce93f8574be2279090ee2aec58b86cda7', 'versionType': 'git'}], 'programFiles': ['fs/hugetlbfs/inode.c', 'include/linux/hugetlb.h', 'include/linux/hugetlb_inline.h', 'mm/hugetlb.c'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '6.19'}, {'status': 'unaffected', 'version': '0', 'lessThan': '6.19', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '7.0.12', 'versionType': 'semver', 'lessThanOrEqual': '7.0.*'}, {'status': 'unaffected', 'version': '7.1', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['fs/hugetlbfs/inode.c', 'include/linux/hugetlb.h', 'include/linux/hugetlb_inline.h', 'mm/hugetlb.c'], 'defaultStatus': 'affected'}] -
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jun. 09, 2026
Action Type Old Value New Value Added Description 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. Added Reference https://git.kernel.org/stable/c/3af5fc3f0ac98c624c109c8c0796fa46e814344c Added Reference https://git.kernel.org/stable/c/83f9efcce93f8574be2279090ee2aec58b86cda7