CVE-2021-47277

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

kvm: avoid speculation-based attacks from out-of-range memslot accesses

KVMs mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvm_memory_slot. The translation is performed in __gfn_to_hva_memslot using the following formula:

  hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE

It is expected that gfn falls within the boundaries of the guests physical memory. However, a guest can access invalid physical addresses in such a way that the gfn is invalid.

__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot does check that the gfn falls within the boundaries of the guests physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva. If the resulting host virtual address is used to load another guest physical address, this is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent on the first.

Right now its not clear if there are any cases in which this is exploitable. One interesting case was reported by the original author of this patch, and involves visiting guest page tables on x86. Right now these are not vulnerable because the hva read goes through get_user(), which contains an LFENCE speculation barrier. However, there are patches in progress for x86 uaccess.h to mask kernel addresses instead of using LFENCE; once these land, a guest could use speculation to read from the VMMs ring 3 address space. Other architectures such as ARM already use the address masking method, and would be susceptible to this same kind of data-dependent access gadgets. Therefore, this patch proactively protects from these attacks by masking out-of-bounds gfns in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.

Sean Christopherson noted that this patch does not cover kvm_read_guest_offset_cached. This however is limited to a few bytes past the end of the cache, and therefore it is unlikely to be useful in the context of building a chain of data dependent accesses.

Weakness

The product reads data past the end, or before the beginning, of the intended buffer.

Affected Software

Potential Mitigations

• Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
• To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/540.html

References

• https://git.kernel.org/stable/c/22b87fb17a28d37331bb9c1110737627b17f6781
• https://git.kernel.org/stable/c/3098b86390a6b9ea52657689f08410baf130ceff
• https://git.kernel.org/stable/c/361ce3b917aff93123e9e966d8608655c967f438
• https://git.kernel.org/stable/c/740621309b25bbf619b8a0ba5fd50a8e58989441
• https://git.kernel.org/stable/c/7af299b97734c7e7f465b42a2139ce4d77246975
• https://git.kernel.org/stable/c/bff1fbf0cf0712686f1df59a83fba6e31d2746a0
• https://git.kernel.org/stable/c/da27a83fd6cc7780fea190e1f5c19e87019da65c
• https://git.kernel.org/stable/c/ed0e2a893092c7fcb4ff7ba74e5efce53a6f5940
• https://git.kernel.org/stable/c/22b87fb17a28d37331bb9c1110737627b17f6781
• https://git.kernel.org/stable/c/3098b86390a6b9ea52657689f08410baf130ceff
• https://git.kernel.org/stable/c/361ce3b917aff93123e9e966d8608655c967f438
• https://git.kernel.org/stable/c/740621309b25bbf619b8a0ba5fd50a8e58989441
• https://git.kernel.org/stable/c/7af299b97734c7e7f465b42a2139ce4d77246975
• https://git.kernel.org/stable/c/bff1fbf0cf0712686f1df59a83fba6e31d2746a0
• https://git.kernel.org/stable/c/da27a83fd6cc7780fea190e1f5c19e87019da65c
• https://git.kernel.org/stable/c/ed0e2a893092c7fcb4ff7ba74e5efce53a6f5940