Bug 921465 - (CVE-2015-0565) VUL-0: CVE-2015-0565: ROWHAMMER: DRAM row corruption
VUL-0: CVE-2015-0565: ROWHAMMER: DRAM row corruption
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
Depends on:
  Show dependency treegraph
Reported: 2015-03-10 07:34 UTC by Marcus Meissner
Modified: 2020-02-27 16:27 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2015-03-10 07:34:30 UTC


“Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process. When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory.

We don’t know for sure how many machines are vulnerable to this attack, or how many existing vulnerable machines are fixable. Our exploit uses the x86 CLFLUSH instruction to generate many accesses to the underlying DRAM, but other techniques might work on non-x86 systems too.

We expect our PTE-based exploit could be made to work on other operating systems; it is not inherently Linux-specific. Causing bit flips in PTEs is just one avenue of exploitation; other avenues for exploiting bit flips can be practical too. Our other exploit demonstrates this by escaping from the Native Client sandbox.

Comment 1 Marcus Meissner 2015-03-10 07:37:35 UTC
The amount of things we can do on the software side is limited.

The exploit relies on /proc/PID/pagemap, which we could avoid providing access to, but this only makes it a bit harder for the exploit.
Comment 2 Marcus Meissner 2015-03-10 14:22:56 UTC
Affectedness can be found out by "dmidecode" and looking for the Error Correction modes of the RAM modules.

None is bad
1 bit error correction is better
multi bit error correct would avoid the problem I guess
Comment 3 Swamp Workflow Management 2015-03-10 23:00:13 UTC
bugbot adjusting priority
Comment 4 Johannes Segitz 2017-08-04 11:43:30 UTC
The various ROWHAMMER attacks improved over the last two years. Since there's not that much we can do about it I don't think we need to keep this bug open