CVE-2024-50115

What it actually does

Failure to mask nCR3[4:0] when loading PDPTEs for nested SVM guests allows an out-of-bounds read from guest memory if the target page sits at the end of a memslot without guard pages.

Why it matters to the business

Virtualized workloads on AMD processors using nested virtualization face a risk of memory disclosure or guest crashes, potentially exposing sensitive data across isolation boundaries in cloud or enterprise hypervisor deployments.

How an attack unfolds

An attacker with control of a nested SVM guest crafts a VMCB whose nCR3 has non-zero bits in positions 4:0, then issues VMRUN; KVM's nSVM path reads PDPTEs without enforcing 32-byte alignment, allowing the read to extend beyond the intended page into adjacent memory.

How to fix it

Update the Linux kernel to a version containing commit 76ce386feb14ec9a460784fcd495d8432acce7a5 or later; rebuild and reboot affected hosts.

How to confirm the fix worked

Confirm the running kernel contains commit 76ce386feb14ec9a460784fcd495d8432acce7a5 via git log or kernel version string; attempt to load a nested SVM guest with deliberately misaligned nCR3 and verify no out-of-bounds access occurs.

Typical attack path

1. Obtain execution inside a nested guest VM under KVM on AMD hardware
2. Prepare a VMCB with nCR3 whose low five bits are nonzero
3. Trigger VMRUN from the guest hypervisor
4. Observe or exfiltrate data read from the resulting out-of-bounds location

How to detect it

Review hypervisor logs and guest VMCB submissions for repeated VMRUN operations with nCR3 values whose low bits are nonzero; correlate with any unexpected page-fault or oops messages referencing PDPTE loads.

What your security team should do

• Prioritize patching KVM hosts that enable nested virtualization on AMD CPUs
• Audit hypervisor configurations to disable nested SVM where not required
• Monitor for guest-initiated VMRUN activity that may exercise the nSVM PDPTE path