Recently fixed in the Linux kernel, CVE-2024-46864 was causing kexec crashes for users running Linux on Hyper-V. If you’re running virtual machines and use kexec — a Linux feature that boots a new kernel without rebooting the entire machine — this is a must-read. Let’s unpack what went wrong, look at the patch, and understand how it could have been exploited.

What Is CVE-2024-46864?

On Linux systems running as virtual machines under Microsoft Hyper-V, the “VP assist page” is a special memory page that enables efficient communication between the guest and the hypervisor. When the system uses kexec to boot into a new kernel, the new kernel must reclaim, re-initialize, and use this page.

The Problem: Due to a faulty logic in the Hyper-V CPU hotplug handling code, the VP assist page was not being reset on kexec. This meant the Hyper-V hypervisor could corrupt (overwrite) memory in the new kernel, potentially leading to crashes, hangs, and system panics.

The Bug

A change was made (commit 9636be85cc5b) to improve CPU state transitions with Hyper-V guests. This added a new “CPU hotplug” state, which is how Linux tracks CPUs as they go online/offline.

However, there was a logic mistake

// When CPUs go offline, this should be called
if (hyperv_init_cpuhp > )
    cpuhp_remove_state(hyperv_init_cpuhp);

The problem? hyperv_init_cpuhp is never > because the new state always returns (unless using a dynamic state, which isn’t the case here!). This means cpuhp_remove_state() is never called.

As a result, the function hv_cpu_die() — which cleans up (resets) the VP assist page for destroyed/offlined CPUs before a kernel kexec — is never called. The old, possibly still-mapped VP assist page sits in memory while the new kernel comes up.

Why Is This Dangerous?

- Memory corruption: If the new kernel unknowingly reassigns that memory for another use, the Hyper-V hypervisor (from the host side) will still think it “owns” that memory as a VP assist page, and will write into it.

Denial-of-Service: Any crash or hang after kexec could mean downtime for your VM fleet.

- Potential code execution: While not explicitly reported, memory corruption like this could, in theory, be exploited for privilege escalation if other factors align.


## Exploiting CVE-2024-46864 (PoC/Scenario)

2. Boot into a running system and run kexec with a new kernel

kexec -l /boot/vmlinuz-NEW --initrd=/boot/initrd-NEW.img --reuse-initrd
kexec -e

3. Observe Hard Crash / Kernel Panic

- The second kernel will try to use random RAM that is silently overwritten by the hypervisor, leading to an unpredictable crash.

> Note: An attacker would need to either cause or predict a kexec, or be able to trigger a virtual CPU offlining event, and then cause kexec.

The Fix — Simple and Elegant

The fix, which landed in commit 9c16cee21ea1, completely removes the unnecessary hyperv_init_cpuhp variable and uses the static state identifier, ensuring cleanup happens:

// Before:
if (hyperv_init_cpuhp > )
    cpuhp_remove_state(hyperv_init_cpuhp);

// After:
cpuhp_remove_state(CPUHP_AP_HYPERV_ONLINE);

This ensures that every time the kernel is preparing for a shutdown or kexec, it properly detaches and resets the VP assist page.

References

- Kernel patch: "x86/hyperv: fix kexec crash due to VP assist page corruption"
- Original bug report on LKML
- Kexec documentation

How To Protect Yourself

- Upgrade your kernel: Make sure your kernel includes the patch for CVE-2024-46864, especially if you run Linux guests under Hyper-V and depend on kexec.
- Audit your VM management routines: If you do automatic live updates or VM mass-migrations using kexec, apply patches quickly.
- Do not ignore kernel panics after kexec in VMs: These may indicate memory corruption as described here.

Conclusion

CVE-2024-46864 reminds us how even small logic errors in kernel housekeeping code can have dangerous edge effects, especially in virtualized environments where host and guest compete for memory. This bug isn’t flashy, but it could knock your cloud infrastructure offline without warning.

Update your kernels. Stay safe.

*If you found this technical note useful, please consider sharing with your Linux sysadmin or virtualization team!*


*(P.S. You can follow further kernel security updates at kernel.org)*

Timeline

Published on: 09/27/2024 13:15:17 UTC
Last modified on: 12/19/2024 09:24:59 UTC