Linux Kernel up to 6.8.7/6.9-rc4 KVM hugepage_has_attrs out-of-bounds

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 4.0 | $0-$5k | 0.00 |
Summary
A vulnerability marked as problematic has been reported in Linux Kernel up to 6.8.7/6.9-rc4. This affects the function hugepage_has_attrs of the component KVM. This manipulation causes out-of-bounds.
This vulnerability is tracked as CVE-2024-26991. No exploit exists.
It is suggested to upgrade the affected component.
Details
A vulnerability classified as problematic was found in Linux Kernel up to 6.8.7/6.9-rc4. Affected by this vulnerability is the function hugepage_has_attrs of the component KVM. The manipulation with an unknown input leads to a out-of-bounds vulnerability. The CWE definition for the vulnerability is CWE-125. The product reads data past the end, or before the beginning, of the intended buffer. As an impact it is known to affect confidentiality. The summary by CVE is:
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---
It is possible to read the advisory at git.kernel.org. This vulnerability is known as CVE-2024-26991 since 02/19/2024. The exploitation appears to be difficult. Technical details of the vulnerability are known, but there is no available exploit.
The vulnerability scanner Nessus provides a plugin with the ID 207776 (Oracle Linux 9 : kernel (ELSA-2024-6997)), which helps to determine the existence of the flaw in a target environment.
Upgrading to version 6.8.8 or 6.9-rc5 eliminates this vulnerability. Applying the patch 048cc4a028e6/992b54bd083c 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.
The vulnerability is also documented in the databases at Tenable (207776) and CERT Bund (WID-SEC-2024-1008). Be aware that VulDB is the high quality source for vulnerability data.
Affected
- Debian Linux
- Amazon Linux 2
- Red Hat Enterprise Linux
- Ubuntu Linux
- SUSE Linux
- Oracle Linux
- Oracle VM
- EMC Avamar
- IBM QRadar SIEM
- Dell NetWorker
- IBM Security Guardium
- RESF Rocky Linux
- Broadcom Brocade SANnav
- Open Source Linux Kernel
- IBM Business Automation Workflow
- IBM Spectrum Protect Plus
- Dell Avamar
- Juniper Junos Space
- IBM DataPower Gateway
- IBM Storage Scale System
- SolarWinds Security Event Manager
- Dell PowerProtect Data Domain
- Dell PowerScale OneFS
Product
Type
Vendor
Name
Version
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔍VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 4.0VulDB Meta Temp Score: 4.0
VulDB Base Score: 2.6
VulDB Temp Score: 2.5
VulDB Vector: 🔍
VulDB Reliability: 🔍
CNA Base Score: 5.5
CNA Vector: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Reliability: 🔍
Exploiting
Class: Out-of-boundsCWE: CWE-125 / CWE-119
CAPEC: 🔍
ATT&CK: 🔍
Physical: Partially
Local: Yes
Remote: Partially
Availability: 🔍
Status: Not defined
EPSS Score: 🔍
EPSS Percentile: 🔍
Price Prediction: 🔍
Current Price Estimation: 🔍
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Nessus ID: 207776
Nessus Name: Oracle Linux 9 : kernel (ELSA-2024-6997)
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔍
Upgrade: Kernel 6.8.8/6.9-rc5
Patch: 048cc4a028e6/992b54bd083c
Timeline
02/19/2024 🔍05/01/2024 🔍
05/01/2024 🔍
02/06/2026 🔍
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2024-26991 (🔍)
GCVE (CVE): GCVE-0-2024-26991
GCVE (VulDB): GCVE-100-262567
CERT Bund: WID-SEC-2024-1008 - Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service
Entry
Created: 05/01/2024 07:44Updated: 02/06/2026 19:13
Changes: 05/01/2024 07:44 (58), 09/28/2024 04:53 (3), 11/07/2024 23:29 (12), 08/03/2025 00:50 (7), 11/11/2025 02:12 (1), 02/06/2026 19:13 (1)
Complete: 🔍
Cache ID: 216::103
Be aware that VulDB is the high quality source for vulnerability data.
No comments yet. Languages: en.
Please log in to comment.