Linux Kernel up to 7.0.11/7.1-rc5 vma_set_flags allocation of resources

Summaryinfo

A vulnerability has been found in Linux Kernel up to 7.0.11/7.1-rc5 and classified as critical. The impacted element is the function vma_set_flags. Performing a manipulation results in allocation of resources. This vulnerability is cataloged as CVE-2026-46318. There is no exploit available. The affected component should be upgraded.

Detailsinfo

A vulnerability was found in Linux Kernel up to 7.0.11/7.1-rc5. It has been classified as critical. This affects the function vma_set_flags. The manipulation with an unknown input leads to a allocation of resources vulnerability. CWE is classifying the issue as CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. The impact remains unknown. The summary by CVE is:

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.

It is possible to read the advisory at git.kernel.org. This vulnerability is uniquely identified as CVE-2026-46318 since 05/13/2026. Technical details of the vulnerability are known, but there is no available exploit.

Upgrading to version 7.0.12 or 7.1-rc6 eliminates this vulnerability. Applying the patch 3af5fc3f0ac98c624c109c8c0796fa46e814344c/83f9efcce93f8574be2279090ee2aec58b86cda7 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

Be aware that VulDB is the high quality source for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.0.0
• 7.0.1
• 7.0.2
• 7.0.3
• 7.0.4
• 7.0.5
• 7.0.6
• 7.0.7
• 7.0.8
• 7.0.9
• 7.0.10
• 7.0.11
• 7.1-rc1
• 7.1-rc2
• 7.1-rc3
• 7.1-rc4
• 7.1-rc5

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Be aware that VulDB is the high quality source for vulnerability data.

Discussion