Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1359 CNY

100%

CVE-2024-26991— KVM: x86/mmu: x86: Don't overflow lpage_info when checking attributes

Quick assessment

Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于允许越界读取。

AI Predicted 7.8 Difficulty: Easy EPSS 0.23% · P13

Affected Version Matrix 6

VendorProduct Version RangeStatus
Linux Linux 90b4fe17981e155432c4dbc490606d0c2e9c2199< 048cc4a028e635d339687ed968985d2d1669494c affected
90b4fe17981e155432c4dbc490606d0c2e9c2199< 992b54bd083c5bee24ff7cc35991388ab08598c4 affected
6.8 affected
< 6.8 unaffected
6.8.8≤ 6.8.* unaffected
6.9≤ * unaffected
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2024-26991

Vulnerability Information

Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
KVM: x86/mmu: x86: Don't overflow lpage_info when checking attributes
Source: CVE Program / CVE List V5
Vulnerability Description
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---
Source: CVE Program / CVE List V5
CVSS Information
N/A
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
Source: CNNVD (China National Vulnerability Database)
Vulnerability Description
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于允许越界读取。
Source: CNNVD (China National Vulnerability Database)
CVSS Information
N/A
Source: CNNVD (China National Vulnerability Database)
Vulnerability Type
N/A
Source: CNNVD (China National Vulnerability Database)

Affected Products

Vendor Product Affected Versions CPE Subscribe
Linux Linux 90b4fe17981e155432c4dbc490606d0c2e9c2199 ~ 048cc4a028e635d339687ed968985d2d1669494c -
Linux Linux 6.8 -

II. Public POCs for CVE-2024-26991

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2024-26991

请登录查看更多情报信息。

Mailing List Discussions for CVE-2024-26991 (3)

Other References for CVE-2024-26991 (2)

Same Patch Batch · Linux · 2024-05-01 · 159 CVEs total

CVE-2024-27388 9.8 CRITICAL SUNRPC: fix some memleaks in gssx_dec_option_array
CVE-2024-26953 9.8 CRITICAL net: esp: fix bad handling of pages from page_pool
CVE-2024-26931 8.8 HIGH scsi: qla2xxx: Fix command flush on cable pull
CVE-2024-27053 8.8 HIGH wifi: wilc1000: fix RCU usage in connect path
CVE-2024-26990 8.8 HIGH KVM: x86/mmu: Write-protect L2 SPTEs in TDP MMU when clearing dirty status
CVE-2024-26952 8.3 HIGH ksmbd: fix potencial out-of-bounds when buffer offset is invalid
CVE-2024-27018 8.2 HIGH netfilter: br_netfilter: skip conntrack input hook for promisc packets
CVE-2024-26936 8.2 HIGH ksmbd: validate request buffer size in smb2_allocate_rsp_buf()
CVE-2024-26980 8.2 HIGH ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf
CVE-2024-26954 8.1 HIGH ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()
CVE-2024-26994 7.8 HIGH speakup: Avoid crash on very long word
CVE-2024-26966 7.8 HIGH clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays
CVE-2024-26974 7.8 HIGH crypto: qat - resolve race condition during AER recovery
CVE-2024-26976 7.8 HIGH KVM: Always flush async #PF workqueue when vCPU is being destroyed
CVE-2024-27062 7.8 HIGH nouveau: lock the client object tree.
CVE-2024-27061 7.8 HIGH crypto: sun8i-ce - Fix use after free in unprepare
CVE-2024-26983 7.8 HIGH bootconfig: use memblock_free_late to free xbc memory to buddy
CVE-2024-27058 7.8 HIGH tmpfs: fix race on handling dquot rbtree
CVE-2024-27056 7.8 HIGH wifi: iwlwifi: mvm: ensure offloading TID queue exists
CVE-2024-27017 7.8 HIGH netfilter: nft_set_pipapo: walk over current view on netlink dump

Showing top 20 of 159 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

V. Comments for CVE-2024-26991

No comments yet


Leave a comment