Intel Core and Xeon CPUs - INTEL-SA-00210: This one is availability, not confidentiality, and it is the most

Impact

This one is availability, not confidentiality, and it is the most operationally brutal item in the family. A malicious guest changes page size in its own page tables so that the instruction TLB holds multiple hits for one address; the CPU raises an unrecoverable machine check and the ENTIRE HOST hangs. One tenant VM, using only its own memory mappings, hard-kills the physical machine - and every other tenant on it. On a GPU host that means every co-resident training job loses its in-flight state back to the last checkpoint, and the node needs a physical or BMC-driven power cycle. It is a one-guest, no-privilege denial of service against the whole box.

Who can reach it

A privileged user inside any guest VM - i.e. root in a tenant's own VM, which on a bare-metal or VM-rental product is something every customer legitimately has. Does not require SMT or core sharing. Container tenants cannot reach it (no control of page tables); VM tenants can.

What to do

Hypervisor patch, plus microcode on some parts. KVM's fix restricts large pages to non-executable mappings and splits huge pages down to 4K the moment a guest executes from them. That is the expensive part: losing 2MB/1GB EPT pages for guest code raises TLB pressure and costs memory-access performance on large-footprint guests, and it burns extra host memory on page tables. Linux exposes kvm.nx_huge_pages=off to reclaim it - do not set that on a multi-tenant host. If you rent whole machines to one tenant at a time, the blast radius is only that tenant and you may reasonably leave huge pages on. Recent Xeon generations are not affected.

References