# rowhammer Published articles for rowhammer. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Security Week 2636: атака GPUThor обходит защиту ECC DevFeed: [Security Week 2636: атака GPUThor обходит защиту ECC]() Original publisher: [Read original article]() Author: Kaspersky\_Lab ("Лаборатория Касперского") Published: 2026-08-31T14:24:08Z Content type: news Language: ru Sources: ["Лаборатория Касперского" RU]() Topics: [rowhammer](), [Security](), [Nvidia]() Tags: [2026](), [ampere](), [gpu](), [nvidia](), [rowhammer](), [security](), [tag-9fe8963de219](), [tag-cc2a6346d835](), [thor]() ### AI overview Researchers from the University of Toronto demonstrated GPUThor, a Rowhammer attack targeting NVIDIA Ampere A4000, A4500, A5000, and A6000 professional GPUs. The attack can produce double and triple bit flips that ECC does not correct, enabling denial-of-service and theoretically creating conditions for privilege escalation. ### Source excerpt Исследователи из канадского Университета Торонто на прошлой неделе опубликовали научную работу, в которой продемонстрировали новую атаку на видеоускорители NVIDIA. Атака, получившая название GPUThor, относится к классу Rowhammer, то есть использует многократные обращения к ячейкам оперативной памяти с целью повлиять на соседние ячейки. Таким образом можно изменить данные в областях памяти, изначально недоступных потенциальному злоумышленнику. Наиболее актуален такой сценарий атаки в случае совместного доступа к профессиональному видеоускорителю. Именно поэтому в подобных работах традиционно исследуются устройства NVIDIA, в данном случае модели поколения Ampere A4000, A4500, A5000 и A6000. По сравнению с предыдущими атаками на подобные устройства, продемонстрированными в начале 2026 года, GPUThor обеспечивает изменение данных в целевых ячейках в сотни и даже тысячи раз чаще. Но самое главное -- новая атака в некоторых случаях приводит к двойным и тройным бит-флипам, которые не корректируются системой ECC. Это точно позволяет провести атаку типа "отказ в обслуживании" и теоретически создает условия для атаки с повышением привилегий, даже если коррекция ошибок включена. Читать далее ## Security Week 2615: атака Rowhammer на видеокарты Nvidia DevFeed: [Security Week 2615: атака Rowhammer на видеокарты Nvidia]() Original publisher: [Read original article]() Author: Kaspersky\_Lab ("Лаборатория Касперского") Published: 2026-04-07T07:58:30Z Content type: news Language: ru Sources: ["Лаборатория Касперского" RU]() Topics: [Nvidia](), [rowhammer](), [Security](), [GeForce](), [ddr5]() Tags: [breach](), [ddr5](), [gddr](), [geforce](), [gpu](), [hammer](), [nvidia](), [rowhammer](), [security](), [tag-9fe8963de219]() ### AI overview The article reports on three research papers describing Rowhammer attacks against Nvidia GPUs with GDDR6 memory, including GeForce RTX 3060 and RTX 6000. The attacks target video-memory page tables and may enable arbitrary reads and writes, with potentially serious consequences for shared cloud systems. ### Source excerpt На прошлой неделе были опубликованы сразу три научные работы, так или иначе предлагающие варианты атаки Rowhammer для видеокарт Nvidia. Подобные атаки часто имеют чисто научный интерес, но не в этом случае: во всех работах показаны методы эксплуатации с реально опасными последствиями вплоть до получения прав суперпользователя на целевой системе. Новые атаки были испытаны на видеокартах с видеопамятью стандарта GDDR6, в частности на GeForce RTX3060 и RTX6000. Именно для RTX6000 и подобных моделей новые атаки наиболее актуальны, так как это промышленный видеоускоритель, часто используемый в облачных решениях с общим доступом к вычислительным ресурсам. Именно там перехват контроля над системой-хостом со стороны клиента представляет наибольшую опасность. Самая первая атака Rowhammer была впервые продемонстрирована в 2014 году в отношении модулей памяти DDR3. Возможность изменения данных в ячейках памяти при обращении к соседним рядам ячеек была известна и ранее, но именно 12 лет назад эту особенность применили для целевого изменения данных в оперативной памяти так, чтобы, например, создать условия для выполнения произвольного кода или похитить секретные данные. С тех пор были предложены как методы противодействия подобным атакам, так и способы их обхода. Последним достижением академических исследователей стала демонстрация атаки "класса" Rowhammer на новейшие модули памяти стандарта DDR5. Читать далее ## Supporting Rowhammer research to protect the DRAM ecosystem DevFeed: [Supporting Rowhammer research to protect the DRAM ecosystem]() Original publisher: [Read original article]() Author: Kimberly Samra (noreply@blogger.com) Published: 2025-09-15T17:01:00Z Content type: article Language: en Sources: [Google Online Security]() Topics: [Hardware](), [Vulnerabilities](), [ddr5](), [Google](), [Security]() Tags: [ddr5](), [dram](), [google](), [hardware](), [none](), [research](), [rowhammer](), [security](), [vulnerabilities]() ### AI overview Google describes Rowhammer as a DRAM hardware vulnerability in which repeated access to memory rows can cause bit flips in adjacent rows. The article explains the security risks, discusses mitigations such as ECC and Target Row Refresh for DDR5, and outlines Google-supported research and test platforms intended to improve defenses. ### Source excerpt Posted by Daniel Moghimi Rowhammer is a complex class of vulnerabilities across the industry. It is a hardware vulnerability in DRAM where repeatedly accessing a row of memory can cause bit flips in adjacent rows, leading to data corruption. This can be exploited by attackers to gain unauthorized access to data, escalate privileges, or cause denial of service. Hardware vendors have deployed various mitigations, such as ECC and Target Row Refresh (TRR) for DDR5 memory, to mitigate Rowhammer and enhance DRAM reliability. However, the resilience of those mitigations against sophisticated attackers remains an open question. To address this gap and help the ecosystem with deploying robust defenses, Google has supported academic research and developed test platforms to analyze DDR5 memory. Our effort has led to the discovery of new attacks and a deeper understanding of Rowhammer on the current DRAM modules, helping to forge the way for further, stronger mitigations. What is Rowhammer? Rowhammer exploits a vulnerability in DRAM. DRAM cells store data as electrical charges, but these electric charges leak over time, causing data corruption. To prevent data loss, the memory controller periodically refreshes the cells. However, if a cell discharges before the refresh cycle, its stored bit may corrupt. Initially considered a reliability issue, it has been leveraged by security researchers to demonstrate privilege escalation attacks. By repeatedly accessing a memory row, an attacker can cause bit flips in neighboring rows. An adversary can exploit Rowhammer via: Reliably cause bit flips by repeatedly accessing adjacent DRAM rows. Coerce other applications or the OS into using these vulnerable memory pages. Target security-sensitive code or data to achieve privilege escalation. Or simply corrupt system's memory to cause denial of service. Previous work has repeatedly demonstrated the possibility of such attacks from software [Revisiting rowhammer, Are we susceptible to rowhammer ## PassMark received offer to not release rowhammer test DevFeed: [PassMark received offer to not release rowhammer test]() Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2015-10-20T19:36:00Z Content type: opinion Language: en Sources: [Mark Seaborn]() Topics: [bug](), [Software](), [systems](), [Maintainers]() Tags: [banking](), [bug](), [devices](), [maintainers](), [medical-devices](), [memory](), [passmark](), [rowhammer]() ### AI overview The article reports that PassMark received an anonymous offer to suppress a rowhammer test for its MemTest86 tool in exchange for payment, but released the software anyway. It discusses the potential implications of rowhammer-related memory unreliability for systems including medical devices, banking systems, and flight control systems. ### Source excerpt Here's an interesting report of skulduggery related to the rowhammer bug. PassMark say they received an offer to not release a rowhammer test in their MemTest86 tool, in return for payment: "We had anonymous contact offering to act as a go between between us and unnamed memory companies, with a view to paying us not release the new version of MemTest86. Who knows how serious the offer was. Needless to say we didn't take up that option, and just released the software anyway. But the issue is a BIG issue. The lack of publicity up to now is somewhat surprising considering the implications. Many computers are fundamentally (slightly) unreliable in a random ways. Maybe this doesn't matter for home use, but for medical devices, banking systems, flight control systems, etc.. it is a big deal." The quoted post is from 20th February 2015 - after the rowhammer bug was publicised by the CMU paper but before we published about the exploitability of the bug. Some background: PassMark are the maintainers of MemTest86. (MemTest86 should not be confused with MemTest86+ which is an alternative, open source fork of the same original codebase.) ## Can cached memory accesses do double-sided row hammering? DevFeed: [Can cached memory accesses do double-sided row hammering?]() Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2015-05-11T22:35:00Z Content type: opinion Language: en Sources: [Mark Seaborn]() Topics: [Cache](), [cpu]() Tags: [cache](), [cpu](), [dram](), [mapping](), [rowhammer](), [xor]() ### AI overview This article examines whether double-sided Rowhammer attacks can be performed using cached memory accesses instead of CLFLUSH. For the author's Sandy Bridge test machine, cache-set, DRAM-bank, and row-address constraints make selecting suitable addresses impossible, leaving single-sided hammering or two sets of 13 addresses as possible approaches. ### Source excerpt There are indications that it is possible to cause bit flips in memory by row hammering without using CLFLUSH, using normal cached memory accesses. This makes me wonder: Is it possible to do double-sided row hammering using cached memory accesses, or only single-sided row hammering? The former is more likely to cause bit flips, and might be the only way to cause bit flips on some machines, such as those using a 2x refresh rate -- i.e. those configured to refresh DRAM every 32ms instead of every 64ms. (See the rowhammer blog post for more background.) The answer appears to be "no" -- at least on my test machine. For this machine (which has a Sandy Bridge CPU), I figured out how physical addresses map to cache sets and to banks and rows in DRAM. We can use these mappings to answer questions about what kinds of row hammering are possible using cached memory accesses. More specifically, my question is this: For a machine with an N-way L3 cache, is it possible to pick N+1 addresses that map to the same cache set, where at least two of these addresses map to rows R-1 and R+1 in one bank (for some neighbouring row R)? If so, repeatedly accessing these addresses would cause cache misses that cause rows R-1 and R+1 to be repeatedly activated. That puts more stress on row R (the victim row) than repeatedly activating only row R-1 or row R+1. The answer to this is "no": It's not possible to pick two such physical addresses. Here's why: Suppose we have two such addresses, A and B. Then: The addresses map to the same bank, so: (1): A[14:17] ^ A[18:21] = B[14:17] ^ B[18:21] (using the bank/row XOR scheme I described previously) The addresses are 2 rows apart, so: (2): A[18:32] + 2 = B[18:32] The addresses map to the same cache set, so: (3): A[6:17] = B[6:17] (also, SliceHash(A[17:32]) = SliceHash(B[17:32]), but we don't need this property) (2) implies that A[19] = ~B[19]. (3) implies that A[14:17] = B[14:17]. Combining that with (1) gives A[18:21] = B[18:21]. That implies A[19] = ## How physical addresses map to rows and banks in DRAM DevFeed: [How physical addresses map to rows and banks in DRAM]() Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2015-05-04T22:57:00Z Content type: article Language: en Sources: [Mark Seaborn]() Topics: [cpu](), [intel](), [bug](), [Testing]() Tags: [cpu](), [dram](), [intel](), [memory](), [rowhammer](), [testing]() ### AI overview The article examines how Intel Sandy Bridge memory controllers map physical addresses to DRAM rows, banks, and columns. Using a vulnerable test machine, it relates the mapping to Rowhammer testing and describes inferring and checking the mapping from observed aggressor and victim addresses. ### Source excerpt In my previous blog post, I discussed how Intel Sandy Bridge CPUs map physical addresses to locations in the L3 cache. Now I'll discuss how these CPUs' memory controllers map physical addresses to locations in DRAM -- specifically, to row, bank and column numbers in DRAM modules. Let's call this the DRAM address mapping. I'll use one test machine as a case study. Motivation: the rowhammer bug I am interested in the DRAM address mapping because it is relevant to the "rowhammer" bug. Rowhammer is a problem with some DRAM modules whereby certain pessimal memory access patterns can cause memory corruption. In these DRAMs, repeatedly activating a row of memory (termed "row hammering") can produce electrical disturbances that produce bit flips in vulnerable cells in adjacent rows of memory. These repeated row activations can be caused by repeatedly accessing a pair of DRAM locations that are in different rows of the same bank of DRAM. Knowing the DRAM address mapping is useful because it tells us which pairs of addresses satisfy this "same bank, different row" (SBDR) property. Guessing and checking an address mapping For my case study, I have a test machine containing DRAM that is vulnerable to the rowhammer problem. Running rowhammer_test on this machine demonstrates bit flips. I'd like to know what the DRAM address mapping is for this machine, but apparently it isn't publicly documented: This machine has a Sandy Bridge CPU, but Intel don't document the address mapping used by these CPUs' memory controllers. rowhammer_test does not actually need to identify SBDR address pairs. rowhammer_test just repeatedly tries hammering randomly chosen address pairs. Typically 1/8 or 1/16 of these pairs will be SBDR pairs, because our machine has 8 banks per DIMM (and 16 banks in total). So, while we don't need to know the DRAM address mapping to cause bit flips on this machine, knowing it would help us be more targeted in our testing. Though the address mapping isn't documented, I fo ## L3 cache mapping on Sandy Bridge CPUs DevFeed: [L3 cache mapping on Sandy Bridge CPUs]() Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2015-04-27T21:59:00Z Content type: article Language: en Sources: [Mark Seaborn]() Topics: [Cache](), [cpu](), [intel](), [systems]() Tags: [cache](), [cpu](), [hash](), [intel](), [kernel](), [memory](), [paper](), [protocol](), [rowhammer](), [side-channel](), [slices](), [xor]() ### AI overview The article explains how physical addresses map to cache sets and slices in the L3 cache of Intel Sandy Bridge CPUs. It reports a previously published mapping for four-core CPUs and presents the author's mapping for two-core CPUs, with applications to kernel ASLR analysis and row-hammering research. ### Source excerpt In 2013, some researchers reverse-engineered how Intel Sandy Bridge CPUs map physical addresses to cache sets in the L3 cache (the last-level cache). They were interested in the cache mapping because it can be used to defeat kernel ASLR. I'm interested because the cache mapping can be used to test whether cached memory accesses can do row hammering (which can cause exploitable bit flips in some DRAM devices). The researchers published the details in the paper "Practical Timing Side Channel Attacks Against Kernel Space ASLR" (Ralf Hund, Carsten Willems and Thorsten Holz). They only published the mapping for 4-core CPUs, but I have figured out the mapping for 2-core CPUs as well. Some background: On Sandy Bridge CPUs, the L3 cache is divided into slices. Physical addresses are hashed to determine which slice of the L3 cache they will be stored in. The L3 cache is distributed and ring-based. There is one slice per core, but all the cores in a CPU can access all the cache slices via a ring bus which connects all the cores and their caches together. When a core accesses a memory location, the location will be slightly slower to access if it maps to a different core's cache slice, because it would take one or two hops around the ring bus to access it. The protocol used on the ring bus is based on QPI (Intel's QuickPath Interconnect). (QPI is a protocol used for connecting multiple CPUs together on high-end multi-socket systems.) Each cache slice contains 2048 cache sets. On lower-end CPUs, cache sets are 12-way associative, so a cache slice is 1.5MB in size (2048 sets * 12 ways * 64 bytes per cache line = 1.5MB). On higher-end CPUs, cache sets are 16-way associative, so a cache slice is 2MB in size (2048 sets * 16 ways * 64 bytes per cache line = 2MB). Cache mapping The researchers (Hund et al) figured out that the L3 cache uses the bits of a physical address as follows: Bits 0-5: These give the 6-bit byte offset within a 64-byte cache line. Bits 6-16: These give the 11-b ## The DRAM rowhammer bug is exploitable DevFeed: [The DRAM rowhammer bug is exploitable]() Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2015-03-10T21:53:00Z Content type: article Language: en Sources: [Mark Seaborn]() Topics: [bug](), [Security](), [Kernel]() Tags: [blog](), [bug](), [dram](), [kernel](), [project](), [rowhammer](), [security]() ### AI overview The article discusses the security implications of the DRAM rowhammer bug and notes published findings on exploiting it to gain kernel privileges. ### Source excerpt I've been researching the DRAM rowhammer issue and its security implications for a while. We've finally published our findings on the Project Zero blog: Exploiting the DRAM rowhammer bug to gain kernel privileges.