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

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: x86: Don't overflow lpageinfo when checking attributes

Fix KVMSETMEMORYATTRIBUTES to not overflow lpageinfo array and trigger KASAN splat, as seen in the privatememconversionstest 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 'lpageinfo' on the memslot, of ‘kvmlpageinfo’ structs. Each index of lpageinfo contains a vmalloc allocated array of these for a specific supported page size. The kvmlpageinfo 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 kvmlpageinfo 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 KVMSETMEMORYATTRIBUTES ioctl KVM updates lpageinfo for each memslot in the range that has mismatched attributes. KVM does this a memslot at a time, and marks a special bit, KVMLPAGEMIXEDFLAG, in the kvmlpageinfo 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 KVMLPAGEMIXEDFLAG is set because it has mixed attributes.

To determine whether a huge page has consistent attributes, the KVMSETMEMORYATTRIBUTES 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 hugepagehasattrs().

Unfortunately, although the kvmlpageinfo 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 kvmlpageinfo 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 KVMLPAGEMIXEDFLAG is not required to prevent huge pages as discussed earlier. But for memslots that are smaller than the 1GB page size, it does call hugepagehasattrs(). In this case the huge page is both the head and tail page. The issue can be observed simply by compiling the kernel with CONFIGKASANVMALLOC and running the selftest “privatememconversionstest”, which produces the output like the following:

BUG: KASAN: vmalloc-out-of-bounds in hugepagehasattrs+0x7e/0x110 Read of size 4 at addr ffffc900000a3008 by task privatememcon/169 Call Trace: dumpstacklvl printreport ? virtaddrvalid ? hugepagehasattrs ? hugepagehasattrs kasanreport ? hugepagehasattrs hugepagehasattrs kvmarchpostsetmemoryattributes kvmvmioctl

It is a little ambiguous whether the unaligned head page (in the bug case also the tail page) should be expected to have KVMLPAGEMIXEDFLAG set. It is not functionally required, as the unal ---truncated---