GPU VulnDB

Database/Control plane, storage & DevOps

DDR3 and DDR4 DRAM, including ECC modules; tracked by Intel as a partial-physical-address disclosure issue: Turns

CVE-2019-0174Control plane, storage & DevOpsRAMBleedINTEL-SA-00247curated

Impact

Turns Rowhammer from a write primitive into a read primitive. The attacker does not corrupt the victim's data - they observe whether their own bits flip, which is data-dependent on the neighbouring row's contents, and read the victim's memory out that way. The published result was extraction of a 2048-bit OpenSSH RSA host key from another process at about 0.3 bits per second. Because it is read-only, ECC does not stop it and nothing in the victim's process ever misbehaves, so there is no detection surface at all. The low CVSS is misleading for a multi-tenant operator: the practical claim is cross-tenant key theft with no artefact.

Who can reach it

Unprivileged local code sharing DRAM with the victim - a container, a VM, or a co-scheduled batch job. The attacker needs to get their pages physically adjacent to the victim's, which memory-massaging techniques make reliable on a busy host.

What to do

No patch. ECC does not help - the attack never needs a flip to survive. Refresh-rate increases raise cost but do not close it. The controls that work: keep untrusted tenants off shared memory controllers, and at the application layer make the secrets worth less by rotating keys aggressively and using memory-hard or constantly-rekeyed representations for long-lived secrets on shared hosts. If you host customer inference on shared CPU memory, assume any long-lived key resident there is readable by a co-tenant given hours.

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.