Database/Control plane, storage & DevOps

DDR4 DRAM with in-DRAM TRR; a coupling effect that reaches rows at distance two rather than immediate neighbours

UnscoredNCVD-2021-002-ddr4-dram-with-in-dram-trr-a-couControl plane, storage & DevOpsHalf-Doublecurated

Impact

Google showed Rowhammer coupling is not confined to adjacent rows - hammering a row disturbs rows two away, and the mitigation logic that only watches immediate neighbours refreshes exactly the wrong rows. Operationally this means the TRR generation your DIMM vendor sold as a fix has a structural blind spot rather than a tuning problem, and mitigations designed around distance-one coupling need redesign. Same downstream consequences as any Rowhammer primitive: page-table corruption to host escape, or silent corruption of a co-tenant's data with no error signalled.

Who can reach it

Unprivileged local code sharing a memory controller with the victim. No CVE was assigned because this is a property of the DRAM, not a defect in a shippable product.

What to do

Nothing you can install. The industry answer is Refresh Management (RFM) in the DDR5 spec plus revised in-DRAM tracking, which means new DIMMs and a memory-controller generation that drives RFM - capex on a refresh cycle, not a patch window. In the meantime: raise the refresh rate where BIOS allows it, and treat memory-controller sharing between untrusted tenants as a policy you have chosen to accept rather than a boundary you have.

References

https://security.googleblog.com/2021/05/introducing-half-double-new-hammering.html https://github.com/google/hammer-kit

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.