TLDRVuln - Cybersecurity Vulnerabilities Made Simple

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

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---