CVE-2024-26991: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-2024-26991

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: x86: Don't overflow lpage_info when checking attributes Fix KVM_SET_MEMORY_ATTRIBUTES to not overflow lpage_info array and trigger KASAN splat, as seen in the private_mem_conversions_test selftest. When memory attributes are set on a GFN range, that range will have specific properties applied to the TDP. A huge page cannot be used when the attributes are inconsistent, so they are disabled for those the specific huge pages. For internal KVM reasons, huge pages are also not allowed to span adjacent memslots regardless of whether the backing memory could be mapped as huge. What GFNs support which huge page sizes is tracked by an array of arrays 'lpage_info' on the memslot, of ‘kvm_lpage_info’ structs. Each index of lpage_info contains a vmalloc allocated array of these for a specific supported page size. The kvm_lpage_info denotes whether a specific huge page (GFN and page size) on the memslot is supported. These arrays include indices for unaligned head and tail huge pages. Preventing huge pages from spanning adjacent memslot is covered by incrementing the count in head and tail kvm_lpage_info when the memslot is allocated, but disallowing huge pages for memory that has mixed attributes has to be done in a more complicated way. During the KVM_SET_MEMORY_ATTRIBUTES ioctl KVM updates lpage_info for each memslot in the range that has mismatched attributes. KVM does this a memslot at a time, and marks a special bit, KVM_LPAGE_MIXED_FLAG, in the kvm_lpage_info for any huge page. This bit is essentially a permanently elevated count. So huge pages will not be mapped for the GFN at that page size if the count is elevated in either case: a huge head or tail page unaligned to the memslot or if KVM_LPAGE_MIXED_FLAG is set because it has mixed attributes. To determine whether a huge page has consistent attributes, the KVM_SET_MEMORY_ATTRIBUTES operation checks an xarray to make sure it consistently has the incoming attribute. Since level - 1 huge pages are aligned to level huge pages, it employs an optimization. As long as the level - 1 huge pages are checked first, it can just check these and assume that if each level - 1 huge page contained within the level sized huge page is not mixed, then the level size huge page is not mixed. This optimization happens in the helper hugepage_has_attrs(). Unfortunately, although the kvm_lpage_info array representing page size 'level' will contain an entry for an unaligned tail page of size level, the array for level - 1 will not contain an entry for each GFN at page size level. The level - 1 array will only contain an index for any unaligned region covered by level - 1 huge page size, which can be a smaller region. So this causes the optimization to overflow the level - 1 kvm_lpage_info and perform a vmalloc out of bounds read. In some cases of head and tail pages where an overflow could happen, callers skip the operation completely as KVM_LPAGE_MIXED_FLAG is not required to prevent huge pages as discussed earlier. But for memslots that are smaller than the 1GB page size, it does call hugepage_has_attrs(). In this case the huge page is both the head and tail page. The issue can be observed simply by compiling the kernel with CONFIG_KASAN_VMALLOC and running the selftest “private_mem_conversions_test”, which produces the output like the following: BUG: KASAN: vmalloc-out-of-bounds in hugepage_has_attrs+0x7e/0x110 Read of size 4 at addr ffffc900000a3008 by task private_mem_con/169 Call Trace: dump_stack_lvl print_report ? __virt_addr_valid ? hugepage_has_attrs ? hugepage_has_attrs kasan_report ? hugepage_has_attrs hugepage_has_attrs kvm_arch_post_set_memory_attributes kvm_vm_ioctl It is a little ambiguous whether the unaligned head page (in the bug case also the tail page) should be expected to have KVM_LPAGE_MIXED_FLAG set. It is not functionally required, as the unal ---truncated---

AI Analysis

Technical Summary

CVE-2024-26991 is a medium severity vulnerability in the Linux kernel's KVM (Kernel-based Virtual Machine) subsystem, specifically related to the handling of huge pages and memory attributes in the x86 architecture's memory management unit (MMU). The flaw arises in the KVM_SET_MEMORY_ATTRIBUTES ioctl operation, which is responsible for setting memory attributes on guest frame number (GFN) ranges. The vulnerability is due to an overflow in the 'lpage_info' array, which tracks supported huge page sizes and their attributes for memory slots (memslots) used by KVM. This array of 'kvm_lpage_info' structs is vmalloc-allocated per memslot and page size, and it includes entries for unaligned head and tail huge pages. The vulnerability occurs because the optimization in the helper function hugepage_has_attrs() assumes that level - 1 huge pages are always aligned and present in the array, but in reality, the level - 1 array may not contain entries for all GFNs at the larger page size level. This mismatch causes an out-of-bounds read from the vmalloc array, which is detected by Kernel Address Sanitizer (KASAN) as a vmalloc-out-of-bounds error. The issue manifests when memory attributes are inconsistent across a memslot, triggering the KVM_LPAGE_MIXED_FLAG bit setting and causing the overflow during attribute checks. While the vulnerability does not impact confidentiality or integrity directly, it causes a denial of service (DoS) by crashing the kernel or triggering KASAN splats. The flaw is reproducible by running the private_mem_conversions_test selftest with KASAN enabled. The vulnerability affects Linux kernel versions containing the specified commit hashes prior to the fix. The CVSS 3.1 score is 5.5 (medium), reflecting local attack vector, low complexity, low privileges required, no user interaction, and impact limited to availability. No known exploits are reported in the wild as of the publication date.

Potential Impact

For European organizations, the primary impact of CVE-2024-26991 is the potential for denial of service in environments running KVM-based virtualization on affected Linux kernels. This can disrupt critical virtualized workloads, including cloud services, private data centers, and enterprise virtualization platforms. Organizations relying on Linux KVM for hosting virtual machines may experience unexpected kernel crashes or instability when memory attributes are changed or manipulated, potentially leading to service outages. Although the vulnerability does not allow privilege escalation or data leakage, the availability impact can affect business continuity, especially for sectors with high virtualization dependency such as finance, telecommunications, and government. Additionally, organizations using automated testing or kernel debugging tools with KASAN enabled may observe test failures or instability. The vulnerability's requirement for local privileges and no user interaction limits remote exploitation, but insider threats or compromised local accounts could trigger the issue. Given the widespread use of Linux and KVM in European cloud providers and enterprises, the risk of operational disruption is significant if unpatched.

Mitigation Recommendations

European organizations should prioritize applying the official Linux kernel patches that address CVE-2024-26991 as soon as they are available from their Linux distribution vendors. Specifically, kernel updates that fix the overflow in the lpage_info array during KVM_SET_MEMORY_ATTRIBUTES operations must be deployed. Organizations using custom or long-term support kernels should backport the patch or upgrade to a fixed kernel version. Additionally, administrators should audit and restrict local user privileges to minimize the risk of local exploitation. Monitoring kernel logs for KASAN vmalloc-out-of-bounds errors can help detect attempts to trigger the vulnerability. For environments with high virtualization density, consider implementing kernel live patching solutions to reduce downtime during patch deployment. Testing patches in staging environments before production rollout is recommended to ensure stability. Finally, organizations should review and harden their virtualization management policies to prevent unauthorized or unintended memory attribute changes that could trigger the flaw.