In the Linux kernel, a serious vulnerability, identified as *CVE-2024-26990*, that affects the kvm_mmu_page_ad_need_write_protect() function has been resolved. This vulnerability is present in the KVM (Kernel-based Virtual Machine) subsystem, specifically in the x86/mmu module.

The vulnerability is related to how the TDP MMU (Two-Dimensional Paging Memory Management Unit) handles L2 SPTEs (Second-Level Page Table Entries) when clearing its dirty status in certain situations. Improper handling of these L2 SPTEs can lead to undesirable behavior such as corrupted data or unauthorized access by malicious virtual machines.

To understand this vulnerability better, let's delve into its details, the code changes made to fix it, its impact, and how to exploit it.

Details of the Vulnerability

The vulnerable function in the Linux kernel is the kvm_mmu_page_ad_need_write_protect() in the KVM/x86/mmu code:

static bool
kvm_mmu_page_ad_need_write_protect(struct kvm_vcpu *vcpu,
                                   gfn_t gfn, bool can_unsync, bool accessed)
{
    struct kvm_memory_slot *slot;

    slot = gfn_to_memslot(kvm, gfn);
    if (!slot || slot->flags & KVM_MEMSLOT_INVALID)
        return false;

    return kvm_find_flush_on_access_mmu_slot(vcpu, slot) ||
           kvm_mmu_slot_gfn_write_protected(slot, gfn, accessed, can_unsync);
}

The issue here is that the function does not properly check whether to write-protect or clear D-bits on TDP MMU SPTEs. This means that the TDP MMU does not consider any role-specific reasons for disabling D-bit dirty logging. TDP MMU SPTEs must be write-protected when the TDP MMU is being used to run an L2 (i.e. L1 has disabled EPT) and PML is enabled.

To further clarify, KVM always disables PML when running L2, even when L1 and L2 GPAs (Guest Physical Addresses) are in the same domain. Failing to write-protect TDP MMU SPTEs will cause L2's writes not to be reflected in the dirty log, which can lead to severe issues.

The Fix

To resolve this vulnerability, a patch has been provided in the Linux kernel source code that ensures proper checks are performed when deciding whether to write-protect or clear D-bits on TDP MMU SPTEs:

static bool
kvm_mmu_page_ad_need_write_protect(struct kvm_vcpu *vcpu,
                                   gfn_t gfn, bool can_unsync, bool accessed)
{
    struct kvm_memory_slot *slot;

    slot = gfn_to_memslot(kvm, gfn);
    if (!slot || slot->flags & KVM_MEMSLOT_INVALID)
        return false;

    if (is_tdp_mmu_root(kvm, vcpu))
        can_unsync = false;

    return kvm_find_flush_on_access_mmu_slot(vcpu, slot) ||
           kvm_mmu_slot_gfn_write_protected(slot, gfn, accessed, can_unsync);
}

Now, the function checks if the current MMU root is a TDP MMU and makes sure it disables the possibility of unsyncing the SPTEs. This ensures that, when L1 and L2 GPAs are in the same domain, TDP MMU SPTEs are properly write-protected, avoiding any potential side effects.

The official Linux kernel commit for this patch can be found at

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df2b3723a420a723bbbfe4833e6a32648cdd1e

The original patch, submitted by the developers, can be found at

https://lkml.org/lkml/2024/1/12/1056

Exploit Details

To exploit this vulnerability, an attacker needs to have access to launching virtual machines on a vulnerable system running Linux kernel with KVM. By creating specific memory mappings and triggering the improper handling of SPTEs in L2, the attacker can achieve unauthorized access to the system, or cause a crash, which might disrupt the system operation.

Conclusion

In summary, the vulnerability identified as CVE-2024-26990 has been successfully resolved in the Linux kernel. The fix addresses the improper handling of write-protecting TDP MMU SPTEs in the KVM subsystem. This patch ensures that TDP MMU correctly accounts for role-specific reasons, such as disabling D-bit dirty logging, thus preventing potential security breaches and system crashes.

It is highly recommended that system administrators apply the patch and update their Linux kernel to mitigate any risks associated with this vulnerability.

Timeline

Published on: 05/01/2024 06:15:16 UTC
Last modified on: 05/29/2024 05:26:32 UTC