CVE-2024-36912

What it actually does

In confidential compute VMs the untrusted host can force set_memory_encrypted or set_memory_decrypted calls to fail, leaving pages in a decrypted shared state that vmbus_establish_gpadl and vmbus_teardown_gpadl then return to the page allocator.

Why it matters to the business

Confidential VMs running on affected kernels risk memory disclosure or corruption that can undermine the confidentiality guarantees of the VM and lead to data leakage or denial of service.

How an attack unfolds

An attacker controlling the host induces a failure in the memory encryption status change inside vmbus_gpadl handling; the resulting shared pages are freed back to the allocator, allowing subsequent allocations to receive pages whose contents are visible to or modifiable by the host.

How to fix it

Update the Linux kernel to a version containing commit 1999644d95194d4a58d3e80ad04ce19220a01a81 or later; rebuild and deploy the new kernel on all CoCo VM hosts.

How to confirm the fix worked

Confirm the running kernel contains commit 1999644d95194d4a58d3e80ad04ce19220a01a81; verify that vmbus_gpadl now stores a decryption-status flag and that callers check it before freeing buffers.

Typical attack path

1. Host triggers failure path in set_memory_decrypted during vmbus_gpadl setup
2. Kernel proceeds without tracking the decryption error
3. Decrypted pages are released to the buddy allocator
4. Attacker observes or tampers with data placed in those pages by other kernel subsystems or user processes

How to detect it

Examine kernel build logs and running kernel version strings for the presence of the fix commit; no runtime indicators are published for prior exploitation of this issue.

What your security team should do

• Prioritize patching of all confidential-compute Linux kernels within the next maintenance window
• Add the fixed commit hash to the organization's kernel baseline and CI build checks
• Monitor upstream stable branches for any follow-on fixes related to vmbus_gpadl handling