CVE-2021-47217

What it actually does

NULL pointer dereference in set_hv_tscchange_cb() when hv_vp_index array is absent after failed Hyper-V initialization, despite the kernel reporting Hyper-V presence.

Why it matters to the business

Kernel crash and system reboot or hang during boot or early initialization on affected Linux kernels running under Hyper-V, leading to downtime in virtualized workloads.

How an attack unfolds

An attacker with the ability to influence early kernel boot under a misconfigured Hyper-V environment triggers the callback registration path that dereferences a NULL hv_vp_index array, causing an immediate kernel panic.

How to fix it

Upgrade to a Linux kernel containing the fix for this NULL dereference in the Hyper-V TSC callback path.

How to confirm the fix worked

Confirm the hv_vp_index NULL check exists in set_hv_tscchange_cb() and that the kernel no longer panics when Hyper-V setup fails.

Typical attack path

1. Hyper-V enlightenments partially initialize then fail silently in hyperv_init()
2. Kernel still sets running-under-Hyper-V flag
3. KVM or VMX initialization calls set_hv_tscchange_cb()
4. Function dereferences hv_vp_index without a NULL check
5. Kernel panics with NULL pointer dereference

How to detect it

Inspect kernel logs for oops messages containing set_hv_tscchange_cb and NULL pointer dereference at address 0000000000000010 during early boot on Hyper-V guests.

What your security team should do

• Apply the upstream kernel patch or distribution update that adds the hv_vp_index validity check
• Test boot under Hyper-V with deliberate hyperv_init() failure scenarios
• Monitor for kernel oops reports referencing set_hv_tscchange_cb during early boot