GPU VulnDB

Database/Control plane, storage & DevOps

DDR4 / LPDDR4 DRAM - Target Row Refresh mitigation: Many-sided Rowhammer defeats the in-DRAM Target Row Refresh

CVE-2020-10255Control plane, storage & DevOpsTRRespasscurated

Impact

Many-sided Rowhammer defeats the in-DRAM Target Row Refresh mitigation that vendors marketed as making Rowhammer solved. On a GPU host node this is the substrate under your host memory: bit flips in page tables or in a hypervisor's structures are a classic path to cross-VM compromise, and on a bare-metal GPU rental it is a path from tenant code to host.

Who can reach it

Local code on the node with the ability to allocate and access memory at a controlled rate. Any tenant container or VM qualifies; no privileges needed.

What to do

No universal fix. Practical controls, in order of value: use ECC DIMMs and actually monitor correctable-error rates (a Rowhammer campaign shows up as a correctable-error storm before it succeeds), enable the platform's refresh-rate and RFM settings in BIOS where offered, and prefer DDR5 modules with on-die ECC. Cost: a BIOS setting change is a drain and reboot; a DIMM refresh is a hardware refresh cycle. Effectively UNPATCHABLE in software.

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.