CVE-2024-46864

What it actually does

Failure to reset the VP assist page on CPU offline during shutdown because cpuhp_remove_state() is never invoked for the non-dynamic cpuhp state, leaving stale hypervisor mappings that corrupt memory when the kexec kernel re-initializes the same page.

Why it matters to the business

Unexpected kernel panics or hangs can occur on Hyper-V systems when performing kexec-based restarts or updates, disrupting planned maintenance windows, live patching, or high-availability failover procedures.

How an attack unfolds

An attacker with local root access on a Hyper-V Linux guest triggers a kexec reboot; because hv_cpu_die() is skipped, the VP assist page is not reset, the hypervisor overwrites the old page contents, and the incoming kernel panics when it re-uses that memory region.

How to fix it

Upgrade the Linux kernel to a version containing commit 2ae1beb3ab4f28868cc5d1541d05e1fbee3ad825 or later; remove reliance on the dynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with cpuhp_remove_state().

How to confirm the fix worked

Confirm the presence of commit 2ae1beb3ab4f or newer in the running kernel; verify that cpuhp_remove_state() is called unconditionally for HYPERV_ONLINE and that no dynamic hyperv_init_cpuhp variable remains.

Typical attack path

1. Obtain local root privileges on target Hyper-V guest
2. Invoke kexec or equivalent kernel restart mechanism
3. Trigger hypervisor corruption of unreleased VP assist page
4. Cause panic in kexec kernel when page is reused

How to detect it

Review kernel logs around kexec or reboot events for hypervisor page corruption panics; examine dmesg or journalctl output for messages referencing VP assist page or hv_cpu_die failures.

What your security team should do

• Prioritize kernel updates on all Hyper-V Linux guests before the next maintenance window
• Test kexec and fast-reboot paths in staging environments after patching
• Monitor vendor advisories for backports to supported distribution kernels