GPU VulnDB

Database/Control plane, storage & DevOps

Arm Neoverse V1 / V2 / V3 / V3AE / N2 and Cortex-A77/A78/A710/X1-X925 cores with Hardware Page Aggregation enabled

CVE-2024-5660Control plane, storage & DevOpsTFV-12Hardware Page Aggregation bypassHPA erratumcurated

Impact

A guest can defeat Stage-2 translation, meaning the hypervisor's memory isolation for that VM stops holding. On a multi-tenant Arm host this is a tenant-to-hypervisor escape, and from there a read of every other VM resident on the socket. It also breaks Granule Protection Table checks, so if you are relying on Arm CCA / Realm confidentiality to sell 'the operator cannot see your model', that guarantee is void on affected silicon. Neoverse V2 is the Grace core, V1/V2 are Graviton3/Graviton4, N2 ships in several Arm server parts, so this touches most of the Arm side of an AI fleet.

Who can reach it

Unprivileged or kernel-level code inside any guest VM on an affected Arm host, with no special device access. No physical access, no network reachability, nothing but a VM on the box.

What to do

This is silicon errata, so the fix is firmware discipline, not a code patch: EL3 firmware must set CPUECTLR_EL1[46]=1 to disable hardware page aggregation on every affected core. That means an updated TF-A / BL31 build from the platform OEM, flashed to each node, with a reboot and therefore a job drain. Ampere, NVIDIA and cloud OEMs each ship their own TF-A fork, so you wait on your board vendor, not on Arm. Budget a rolling reboot of the whole Arm fleet. There is a small performance cost to losing HPA on large-page workloads; measure before assuming it is free.

References

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.