Linux Kernel up to 6.18.34/7.0.11/7.1-rc6 KVM kvm_unmap_gfn_range nested_mmus[] buffer overflow

Summaryinfo

A vulnerability identified as critical has been detected in Linux Kernel up to 6.18.34/7.0.11/7.1-rc6. This affects the function kvm_unmap_gfn_range of the component KVM. Performing a manipulation of the argument nested_mmus[] results in buffer overflow. This vulnerability is known as CVE-2026-46317. No exploit is available. You should upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as critical, was found in Linux Kernel up to 6.18.34/7.0.11/7.1-rc6. This affects the function kvm_unmap_gfn_range of the component KVM. The manipulation of the argument nested_mmus[] with an unknown input leads to a buffer overflow vulnerability. CWE is classifying the issue as CWE-120. The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Reassign nested_mmus array behind mmu_lock kvm->arch.nested_mmus[] is walked under kvm->mmu_lock, including from the MMU notifier path (kvm_unmap_gfn_range() -> kvm_nested_s2_unmap()), which can run at any time. kvm_vcpu_init_nested() reallocates the array and frees the old buffer while holding only kvm->arch.config_lock, so such a walker can reference the freed array. Allocate the new array outside of mmu_lock, as the allocation can sleep. Under the lock, copy the existing entries, fix up the back pointers and reassign the array. Free the old buffer after dropping the lock, as kvfree() can sleep as well.

The advisory is shared at git.kernel.org. This vulnerability is uniquely identified as CVE-2026-46317 since 05/13/2026. The exploitability is told to be easy. Technical details are known, but no exploit is available. The price for an exploit might be around USD $5k-$25k at the moment (estimation calculated on 06/09/2026).

Upgrading to version 6.18.35, 7.0.12 or 7.1-rc7 eliminates this vulnerability. Applying the patch 918450ad6010df6ecd2efde12a1409e011da22d6/4424dbcb06d68e34e51c019a5781a7dc00731971/70543358fa08e0f7cebc3447c3b70fe97ad7aaa8 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.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.18.16
• 6.18.17
• 6.18.18
• 6.18.19
• 6.18.20
• 6.18.21
• 6.18.22
• 6.18.23
• 6.18.24
• 6.18.25
• 6.18.26
• 6.18.27
• 6.18.28
• 6.18.29
• 6.18.30
• 6.18.31
• 6.18.32
• 6.18.33
• 6.18.34
• 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
• 7.1-rc6

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

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion