Linux Kernel
CVE-2024-36912
CRITICAL
Severity by source
AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Attacker must be the untrusted hypervisor and reliably force a memory-conversion failure (AV:L, AC:H, PR:H); impact is mainly disclosure of leaked shared pages (C:H) with limited integrity and no availability effect.
Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).
CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Lifecycle Timeline
5DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Track decrypted status in vmbus_gpadl
In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.
In order to make sure callers of vmbus_establish_gpadl() and vmbus_teardown_gpadl() don't return decrypted/shared pages to allocators, add a field in struct vmbus_gpadl to keep track of the decryption status of the buffers. This will allow the callers to know if they should free or leak the pages.
AnalysisAI
Memory-safety hardening gap in the Linux kernel's Hyper-V VMBus GPADL handling (Drivers: hv: vmbus) lets an untrusted hypervisor host force set_memory_encrypted()/set_memory_decrypted() to fail inside Confidential Computing (CoCo) guests, so decrypted (shared) pages can be returned to the page allocator on error. The fix adds a decrypted-status field to struct vmbus_gpadl so callers of vmbus_establish_gpadl()/vmbus_teardown_gpadl() can decide to free or deliberately leak affected pages. This is a defense-in-depth fix for the CoCo threat model rather than a conventional remotely exploitable flaw; no public exploit identified at time of analysis and EPSS is low (0.92%, 56th percentile).
Technical ContextAI
The affected component is the Hyper-V VMBus transport layer (drivers/hv/), which sets up guest-physical-address descriptor lists (GPADLs) to share ring buffers between a Linux guest and the Hyper-V host. In Confidential Computing VMs (AMD SEV-SNP / Intel TDX), guest memory is encrypted by hardware and pages are explicitly toggled shared/private via set_memory_decrypted()/set_memory_encrypted(). Because the host is outside the guest trust boundary, it can induce these calls to fail, leaving a page in the shared (decrypted) state while the guest believes it was re-encrypted. Prior to this change the kernel did not track that state, so an error path could hand a still-shared page back to the allocator for arbitrary reuse. This maps to CWE-1258 (exposure of sensitive information / improper handling of memory state), and the root-cause class is unhandled error returns leaving memory in an inconsistent encryption state.
RemediationAI
Patch available per vendor advisory: update to a Linux kernel build that includes the vmbus_gpadl decrypted-tracking fix, applied via the kernel.org stable commits 1999644d, 211f514e, 8e62341f, and bfae56be (https://git.kernel.org/stable/c/1999644d95194d4a58d3e80ad04ce19220a01a81 and the three sibling commits) - consume the fix through your distribution's patched stable/LTS kernel rather than building from a specific 6.9 release candidate. Because this only matters inside Confidential Computing guests, the practical compensating control where immediate patching is not possible is to run affected Hyper-V Linux guests without confidential-computing (SEV-SNP/TDX) memory encryption enabled, or on a trusted hypervisor, which removes the untrusted-host precondition entirely; the trade-off is loss of the CoCo confidentiality guarantee, so this is only acceptable in environments where the host is already trusted. No exact tagged release version is stated in the input, so cite the stable commit hashes rather than an invented version number.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today