Table of Contents
Fetching ...

GbHammer: Malicious Inter-process Page Sharing by Hammering Global Bits in Page Table Entries

Keigo Yoshioka, Soramichi Akiyama

TL;DR

GbHammer reveals a previously overlooked RowHammer-based risk: flipping the global bit in a PTE can cause cross-process address translations to share a physical page, enabling an attacker to coerce a victim into executing attacker code or to snoop on secret data. The authors formalize the threat model, show a three-step mechanism to establish a shared page, and validate two exploits—arbitrary binary execution and data snooping—using a cycle-accurate gem5 simulation and a Linux kernel. They also discuss mitigation strategies across OS, loader, and hardware configurations, and consider implications for ARMv7 and RISC-V. The work highlights a practical attack surface in modern memory hierarchy design and motivates cross-layer defenses to prevent global-bit misuse.

Abstract

RowHammer is a vulnerability inside DRAM chips where an attacker repeatedly accesses a DRAM row to flip bits in the nearby rows without directly accessing them. Several studies have found that flipping bits in the address part inside a page table entry (PTE) leads to serious security risks such as privilege escalation. However, the risk of management bits in a PTE being flipped by RowHammer has not yet been discussed as far as we know. In this paper, we point out a new vulnerability called GbHammer that allows an attacker to maliciously share a physical memory page with a victim by hammering the global bit in a PTE. GbHammer not only creates a shared page but also enables the attacker to (1) make the victim's process execute arbitrary binary and (2) snoop on the victim's secret data through the shared page. We demonstrate the two exploits on a real Linux kernel running on a cycle-accurate CPU simulator. We also discuss possible mitigation measures for GbHammer and the risk of GbHammer in non-x86 ISAs.

GbHammer: Malicious Inter-process Page Sharing by Hammering Global Bits in Page Table Entries

TL;DR

GbHammer reveals a previously overlooked RowHammer-based risk: flipping the global bit in a PTE can cause cross-process address translations to share a physical page, enabling an attacker to coerce a victim into executing attacker code or to snoop on secret data. The authors formalize the threat model, show a three-step mechanism to establish a shared page, and validate two exploits—arbitrary binary execution and data snooping—using a cycle-accurate gem5 simulation and a Linux kernel. They also discuss mitigation strategies across OS, loader, and hardware configurations, and consider implications for ARMv7 and RISC-V. The work highlights a practical attack surface in modern memory hierarchy design and motivates cross-layer defenses to prevent global-bit misuse.

Abstract

RowHammer is a vulnerability inside DRAM chips where an attacker repeatedly accesses a DRAM row to flip bits in the nearby rows without directly accessing them. Several studies have found that flipping bits in the address part inside a page table entry (PTE) leads to serious security risks such as privilege escalation. However, the risk of management bits in a PTE being flipped by RowHammer has not yet been discussed as far as we know. In this paper, we point out a new vulnerability called GbHammer that allows an attacker to maliciously share a physical memory page with a victim by hammering the global bit in a PTE. GbHammer not only creates a shared page but also enables the attacker to (1) make the victim's process execute arbitrary binary and (2) snoop on the victim's secret data through the shared page. We demonstrate the two exploits on a real Linux kernel running on a cycle-accurate CPU simulator. We also discuss possible mitigation measures for GbHammer and the risk of GbHammer in non-x86 ISAs.
Paper Structure (25 sections, 5 figures, 1 table)

This paper contains 25 sections, 5 figures, 1 table.

Figures (5)

  • Figure 1: Malicious Page Sharing by GbHammer
  • Figure 2: Binary Execution Exploit
  • Figure 3: Victim Code for the Binary Execution Experiment
  • Figure 4: Timeline of the Binary Execution Exploit
  • Figure 5: Result of Binary Execution Experiment