Linux Kernel CVE-2024-36913

Exploitation requires a Confidential Computing deployment: a Linux guest using the Hyper-V VMBus driver inside a hardware-encrypted VM (AMD SEV-SNP or Intel TDX) under an untrusted/malicious hypervisor. The specific trigger is the host forcing set_memory_encrypted() or set_memory_decrypted() to return an error during VMBus buffer handling, leaving a page in the shared/decrypted state that is then freed to the page allocator. Limiting factors: the attacker must already control the hypervisor (the CoCo untrusted-host role), the target must be a confidential VM (default non-CoCo VMs and bare-metal Linux are unaffected because the host is trusted), and only Hyper-V/VMBus guests are in scope. There is no in-guest unprivileged path and no remote network vector despite the critical score.

The signals are mixed and require interpretation. The published CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, score 9.3) reflects the CoCo threat model in which the untrusted host is the 'local, unprivileged' attacker and the scope change (S:C) captures the crossing of the guest's confidentiality boundary - this is why the score is critical despite AV:L. However, EPSS is only 0.92% (56th percentile), the CVE is NOT in CISA KEV, and no public PoC is referenced, so there is no evidence of real-world exploitation. Realistically, exploitation requires the attacker to already control the hypervisor and target a CoCo guest - a narrow, high-capability, targeted scenario rather than broad opportunistic attack. For conventional (non-confidential) VMs and bare-metal Linux this issue is not applicable because the host is trusted and set_memory_encrypted() paths behave normally. Net assessment: legitimately high severity for the specific CoCo use case, but low operational urgency for the vast majority of Linux deployments; prioritize only where SEV-SNP/TDX guests on Hyper-V are in use.

A malicious or compromised Hyper-V hypervisor hosting a victim SEV-SNP/TDX confidential VM deliberately fails the guest's set_memory_encrypted() call during a VMBus buffer teardown, causing the guest kernel to free a page that remains host-readable (shared). The host then reads confidential data that the guest later allocates into that page, or induces functional corruption. No public exploit code is referenced, and the attack requires full hypervisor control, so it is a targeted rather than opportunistic scenario.