PaperlayerView exact revision on arXiv

Source-linked AI summary

A Rowhammer attack on Fil-C's software capabilities

Amir Naseredini, Suhas Viswanath, Martin Berger

arXiv:2610.33748v1cs.PLcs.CR

TL;DR

Fil-C’s runtime checks assume commodity DRAM preserves the bounds metadata they rely on. The paper combines deterministic fault injection with a physical attack and shows that a single bit flip can bypass those checks in four case studies.

  • Problem

    Fil-C’s runtime checks assume commodity DRAM faithfully preserves the bounds metadata on which they depend.

    Source: §I · p. 1

  • Method

    The paper combines deterministic Rowhammer-like fault injection against Fil-C binaries with a physical end-to-end attack that flips metadata in a live victim.

    Source: §I · p. 2, F. Physical feasibility of delivery · p. 9

  • Results

    A single 0→1 bit flip in Fil-C 0.679’s bounds metadata expanded the permitted range and enabled four case studies, bypassing the runtime’s spatial-safety guarantee.

    Source: §X · p. 13

  • Takeaways & Limitations

    Unauthenticated bounds metadata in commodity DRAM is a structural exposure for compiler-based memory-safety systems.

    Source: Nature of the disclosed weakness · p. 14

    The case-study evaluation models fault delivery out-of-band; the physical attack chain was confirmed on two machines but remains probabilistic.

    Source: C. Limitations · p. 11

Abstract

from arXiv · show

Rowhammer is a hardware vulnerability in dynamic random-access memory (DRAM) in which repeated accesses to one or more aggressor rows can induce bit-flips in nearby victim rows. This phenomenon violates a core assumption of conventional programming language semantics: that reading from or writing to one memory location does not modify others. Despite the security importance of this phenomenon, there is no widely established formal framework connecting Rowhammer faults with program behaviour. This makes it difficult to reason rigorously about the efficacy of proposed Rowhammer defences and the program-level guarantees they provide. To address this gap, we present a probabilistic small-step operational semantics for an idealised imperative language subject to Rowhammer-style faults. The semantics is high-level in that it abstracts from DRAM internals and semiconductor physics. A general probabilistic fault model parameterises the semantics, representing Rowhammer-style faults by assigning probabilities to bit-flips during read or write operations within a specified victim region. The resulting distributions are propagated through programs using the standard monadic structure of probabilistic computation. As a case study, we formalise physical separation, a well-known defence that places program variables sufficiently far apart in physical memory that an access to one variable cannot disturb another. We prove a distribution-independent semantic collapse theorem: for every finite execution, including prefixes of terminating and non-terminating executions, the protected projection of the probabilistic Rowhammer semantics is the Dirac distribution of the corresponding Rowhammer-free execution. Furthermore, we develop an observation-parametric account of secure information flow.

I. INTRODUCTION

The paper presents the first Rowhammer attack on Fil-C, showing how bit flips in unprotected inline capability metadata can silently defeat runtime checks. It combines deterministic fault injection with end-to-end attacks on commodity DDR3 and tested TRR-equipped DDR4, and discusses Fil-C-specific mitigations.

I. INTRODUCTION

  • A suitable bit flip can silently expand a capability’s upper bound and bypass Fil-C checks without a panic, signal, or machine check.The attack depends on a flip that survives constraints including cell location, flip polarity, current bit value, and the requirement that the result remain a valid pointer.Source: §I · pp. 1–2
  • The paper treats Rowhammer mitigation as a hardware responsibility while discussing Fil-C-specific mitigations, including PT-Guard’s MAC protection for a new target.The authors state that they contribute no new class of defence.Source: §I · p. 2
  • The first Rowhammer attack on Fil-C shows that its bounds checks rely on inline capability metadata stored in ordinary DRAM.The paper characterises the Fil-C 0.679 capability layout and states that a usable bit flip in suitable pointer metadata can break that pointer’s spatial-safety promise.Source: §I · pp. 1–2
  • Deterministic single-bit fault injection demonstrates silent runtime-check bypass across four case studies, including privilege escalation and cross-tenant information disclosure.The cases include bounded out-of-bounds read/write access, secret disclosure, flipping an adjacent is_admin field, and API-key leakage from a multi-tenant SQLite-backed credential service.Source: §I · p. 2
  • Capability-aware flip selection and allocator- and offset-aware physical-frame grooming realise the attacks end-to-end on DDR3 and tested TRR-equipped DDR4.The reported exploitation times are 2 minutes on older DDR3 and 10–35 minutes on the tested DDR4 modules; TRR did not prevent delivery on that platform.Source: §I · p. 2

II. BACKGROUND · A. Fil-C, InvisiCaps and FUGC

This background explains how Fil-C’s capability system and FUGC’s allocation behavior create attack-relevant metadata and placement conditions.

II. BACKGROUND

  • Fil-C is memory-safe C/C++ whose compiler and runtime maintain an invisible InvisiCap per pointer, checking dereferences against the capability’s upper bound and the pointer’s lower bound,.The capability is not part of the pointer’s C-level value.Source: A. Fil-C, InvisiCaps and FUGC · p. 2, §II · p. 2

A. Fil-C, InvisiCaps and FUGC

  • Each heap object stores its capability as a plain 16-byte inline DRAM header at a negative offset, while program-visible payload lies at a non-negative offset from the concrete pointer.A Fil-C pointer has two 8-byte components: the lower bound and the concrete pointer.Source: A. Fil-C, InvisiCaps and FUGC · pp. 2–3
  • In Fil-C 0.679, corrupting payload−16 changed zgetupper’s value and enlarged the size reported by zlength; the word has no MAC, parity, or separate tag memory.The layout was checked using the runtime’s zgetlower, zgetupper, and zlength introspection API.Source: A. Fil-C, InvisiCaps and FUGC · p. 3
  • Fil-C’s dereference check panics when ptr >= upper, so it protects an object only if the upper bound has not been silently modified outside the runtime’s view.The observed panic is “cannot read/write pointer with ptr >= upper”.Source: A. Fil-C, InvisiCaps and FUGC · p. 3
  • FUGC is an accurate, concurrent, non-moving mark-and-sweep collector; its libpas-based user-space allocator groups small objects by size class into slab-style pages, [22],.FUGC fixes objects’ virtual layout within an allocator page, but Linux determines the backing physical frame, which the placement harness must observe or revalidate.Source: A. Fil-C, InvisiCaps and FUGC · p. 3
  • Because neither allocation nor collection rechecks bounds against a checksum, corrupted bounds can persist across collection cycles, while Phase 2 exploits predictable size-class and free-list placement.Linux-specific physical placement relies on page-frame recycling, memory-zone locality, and /proc/pid/pagemap; the deterministic path also uses /proc/pid/mem.Source: A. Fil-C, InvisiCaps and FUGC · p. 3

B. DRAM and Rowhammer … B. Attack preconditions

The paper demonstrates Rowhammer delivery on DDR3 and TRR-equipped DDR4 and uses out-of-band corruption to test whether Fil-C detects damage to its capability metadata. It makes explicit the hardware-integrity assumptions Fil-C relies on and the attack preconditions that undermine them.

B. DRAM and Rowhammer

  • Rowhammer repeatedly activates aggressor rows to induce flips in adjacent victim rows, and the paper focuses on consequences built from flips rather than on a specific delivery method.It relies on established double-sided hammering on DDR3 and many-sided hammering on TRR-equipped DDR4.Source: B. DRAM and Rowhammer · p. 3

A. Attacker capabilities

  • The attacker is co-resident with a Fil-C victim and aims to flip one bit in the DRAM cell holding the victim’s InvisiCap upper bound.The key capability is out-of-band modification, which avoids Fil-C-instrumented instructions and their inserted checks; physical Rowhammer has been demonstrated from unprivileged userspace and JavaScript.Source: A. Attacker capabilities · pp. 3–4

Deterministic path (out-of-band injection):

  • A deterministic one-bit corruption makes the complete Fil-C runtime accept an access that the original InvisiCap bound would reject.A same-UID parent writes the modified bound through /proc/pid/mem in the Fil-C 0.679 toolchain experiment; this is reproducible fault injection, not an end-to-end Rowhammer attack.Source: Deterministic path (out-of-band… · p. 4

Physical end-to-end path (bare-metal hammering):

  • The bare-metal engine targets the victim’s InvisiCap word using its physical address from /proc/pid/pagemap and hammers attacker-owned neighboring rows.The evaluation uses double-sided hammering on DDR3 and wide many-sided TRR-evading hammering with physical-frame grooming on DDR4.Source: Physical end-to-end path (bare-metal… · p. 4
  • Usable bit flips are achieved on DDR3 and TRR-equipped DDR4, using classical double-sided hammering on DDR3 and wide many-sided TRR-evading patterns on DDR4.The DDR3 case study also uses out-of-band delivery to isolate the metadata-corruption consequence from physical flip throughput.Source: Physical end-to-end path (bare-metal… · p. 4

B. Attack preconditions

  • The threat model challenges assumptions that InvisiCap metadata is immutable, allocator layout is opaque, attacker rows are physically isolated, and refresh prevents disturbance from accumulating.The text says Rowhammer violates metadata immutability and refresh assumptions, fixed heap state makes the FUGC slab layout deterministic, and Linux does not guarantee physical isolation.Source: B. Attack preconditions · p. 4
  • Both evaluated machines use non-ECC DIMMs, so a single-bit flip is neither detected nor corrected; SECDED would catch the flip the attack relies on.The paper leaves multi-bit ECC bypass, which would require crafted patterns, templating, and fault handling, as future work.Source: B. Attack preconditions · p. 4

IV. ATTACK METHODOLOGY · A. Phase 1: DRAM templating

The attack targets Fil-C’s compiler-managed bounds metadata and delivers a usable capability-word flip through either a physical four-phase pipeline or a deterministic out-of-band write. Phase 1 templates DRAM for a suitable flippy cell, while the physical path uses runtime-recovered geometry and generation-specific hammering.

IV. ATTACK METHODOLOGY

  • The methodology combines frame donation, bank recovery, and many-sided hammering with memory-zone-aware scouting, offset-aware frame selection, one-use capability spraying, and per-candidate no-hammer controls.The physical path executes Phases 1–3 against DRAM before the corrupted InvisiCap silently permits out-of-bounds access in Phase 4; the deterministic path replaces Phases 1–3 with an out-of-band write.Source: §IV · p. 4

A. Phase 1: DRAM templating

  • Phase 1 seeks a reliable 0→1 flippy cell in an object’s inline-header upper-bound word, with bit position k large enough for an expansion of 2^k to reach the target.Once a capability is groomed onto the cell, the word is at payload−16; a few hundred bytes can reach an adjacent object.Source: A. Phase 1: DRAM templating · p. 5

Memory mapping and geometry recovery:

  • The hammer pool uses 2 MiB transparent huge pages for row-offset contiguity, while grooming disables them to enable same-granularity 4 KiB frame reuse between the engine and forked victim.Hammering during grooming relies on the allocator’s longest physically contiguous 4 KiB run, and physical frame numbers come from /proc/self/pagemap.Source: Memory mapping and geometry recovery · p. 5
  • Runtime DRAMA timing recovers same-bank geometry from the approximately 30 ns conflict penalty, avoiding hardcoded mappings and carrying the routine across DDR3 and DDR4 machines.The engine identifies address pairs in the same bank through their bank-conflict latency.Source: Memory mapping and geometry recovery · p. 5

Generation-specific hammering:

  • On DDR3 without TRR, double-sided hammering uses 2.5 million iterations per burst, or 5 million aggressor-row activations, within the module’s 64 ms refresh window.The DDR3-1333 burst completes within that window, allowing disturbance to accumulate between refreshes.Source: Generation-specific hammering · p. 5
  • On the tested TRR-equipped DDR4 module, wide many-sided hammering with decoy rows successfully delivers usable flips without claiming to reproduce Blacksmith’s full non-uniform search.The preset distributes TRR’s limited tracking budget across the true aggressors and many decoy rows, and is evaluated end-to-end on the module.Source: Generation-specific hammering · p. 5
  • The evaluated preset does not use RowPress or depend on disturbance amplification, although such amplification could reduce the activations needed for a flip.RowPress is described as an orthogonal amplification that could lower the activation count, not as part of the evaluated preset.Source: Generation-specific hammering · p. 5

B. Phase 2: grooming

Phase 2 makes capability-word placement predictable through size-class allocation: the deterministic case studies arrange adjacent objects directly, while real hammering uses Flip Feng Shui page-frame grooming. Both approaches rely on same-size-class allocation determinism, but fix different placement targets.

B. Phase 2: grooming

  • In deterministic case studies, 256-byte requests use the 288-byte class with a 304-byte stride, making a same-class secondary object predictably adjacent to the target.The 32-byte slack within the physical slot can expand the usable window if a flip reaches it; the experimental harness publishes the target address and retries allocation until adjacency is obtained.Source: B. Phase 2: grooming · pp. 5–6

Aligning the objects (deterministic case studies):

  • For deterministic alignment, the victim retries allocations that cross a slab boundary and publishes the target address, fixing the upper-bound word at vpayload −16 for the out-of-band flip.The victim allocates the target and, in cross-object cases, a same-size-class secondary object; consecutive increasing slab addresses place the secondary immediately above the target.Source: Aligning the objects (deterministic… · p. 6

Landing a physical flip (Flip Feng Shui grooming):

  • For real hammering, the attacker donates templated flippy frames, sprays same-size-class victim objects until a capability word lands on one, then re-hammers it.Each donation is a single 4 KiB munmap; keeping the frame’s physical address and adjacent aggressors unchanged lets allocator reuse place it under the victim’s capability word. A scout spray identifies the victim’s current memory zone, and offset-aware selection favors frames whose flips affect an exploitable low byte.Source: Landing a physical flip (Flip Feng… · p. 6, Figure 3 · p. 6

C. Phase 3: hammering · D. Phase 4: exploitation

The attack hammers a victim-resident InvisiCap until an upper-bound bit flips, then exploits the enlarged bound for out-of-bounds reads and writes.

C. Phase 3: hammering

  • Phase 3 repeats the generation-appropriate hammer pattern against the same aggressor rows after the InvisiCap enters the victim row.Figure 4 illustrates the row arrangement.Source: C. Phase 3: hammering · p. 6
  • Hammering proceeds in bursts until a flip appears or time expires, with a check after each burst to stop unnecessary activations.Source: C. Phase 3: hammering · p. 6

Mathematical effect:

  • A 0→1 flip at k=30 expands the upper bound by 1 GiB, allowing checks to pass throughout [uorig, uorig + 2^k), including adjacent objects and runtime structures.Source: Mathematical effect · p. 6

D. Phase 4: exploitation

  • The corrupted capability causes no software-visible panic, machine-check exception, or signal; zgetupper and zlength report the enlarged bound, which checks accept.Source: D. Phase 4: exploitation · pp. 6–7

OOB read: confidentiality violation:

  • The victim reads past its original buffer into an adjacent secret token or, in the SQLite service, another tenant’s stored API key; this is not a SQLite vulnerability.Source: OOB read: confidentiality violation · p. 7

OOB write: integrity violation:

  • The expanded bound enables out-of-bounds writes that set an adjacent session object’s is_admin field, while control-flow hijacking is only a plausible, undemonstrated extension.Source: OOB write: integrity violation · p. 7

V. PROOF OF CONCEPT (POC) IMPLEMENTATIONS … VI. EXPERIMENTAL EVALUATION

The PoC tests whether a single flip to Fil-C’s upper-bound metadata permits out-of-bounds access, using either deterministic injection or physical hammering. Generation-specific bare-metal engines deliver physical flips, and the evaluation uses a Flip Feng Shui–style grooming path for its physical end-to-end result.

V. PROOF OF CONCEPT (POC) IMPLEMENTATIONS

  • The primary PoC demonstrates Rowhammer bit flips affecting Fil-C metadata through both deterministic and physical end-to-end paths.The bare-metal drivers implement the physical delivery primitive used by the latter path.Source: §V · p. 7

A. Primary PoC: real-runtime bypass

  • A Fil-C-compiled victim publishes its runtime-assigned object bounds, while an external bare-metal attacker locates the upper-bound cell and applies a single 0→1 flip.The cell is found directly at payload−16 or by scanning writable memory for the published value; the victim’s access is out-of-bounds for the original object.Source: A. Primary PoC: real-runtime bypass · p. 7
  • Four case studies test post-flip behavior: out-of-bounds reads and writes, secret reads across an allocation boundary, privilege escalation via authflag, and over-reading an adjacent admin record in SQLite-backed kv.The deterministic path injects the change through /proc/pid/mem, while the physical path induces the same flip by hammering.Source: A. Primary PoC: real-runtime bypass · p. 7
  • A success report means the runtime permitted the access after a flip; without a flip, the first out-of-bounds access hard-panics and kills the victim before it can report.The harness has no path for reporting that an attempted out-of-bounds access was blocked.Source: A. Primary PoC: real-runtime bypass · p. 7

B. Bare-metal delivery drivers

  • The DDR3 and DDR4 engines use generation-specific hammering and measured DRAM geometry to target the victim’s physical row rather than infer neighboring rows from addresses alone.They self-template on attacker-owned pages, occupy most of RAM, select aggressor rows empirically confirmed to share the victim row’s bank, and poll for a genuine change during a fixed-time hammering loop.Source: B. Bare-metal delivery drivers · p. 7

VI. EXPERIMENTAL EVALUATION

  • The physical end-to-end result used Flip Feng Shui–style grooming: the attacker templates flippy frames, donates them to the allocator, and has the victim place an InvisiCap word on a known-flippy frame before re-hammering.The aggressors remain unchanged during the re-hammering step.Source: B. Bare-metal delivery drivers · p. 7

B. Bare-metal delivery drivers

  • The engine counts a flip as exploitable only when it expands the bound and preserves pointer validity; deterministic self-test validates the exploit chain, while hammering requires susceptible DRAM.Flips failing either exploitability condition are reported as unusable rather than counted as bypasses.Source: B. Bare-metal delivery drivers · p. 8

A. Setup … authflag:

On a real Fil-C runtime, one out-of-band bit flip corrupting an object’s upper bound allowed accesses that otherwise hard-panic. The setup and case studies show this metadata corruption can enable bounded out-of-bounds reads and writes, including disclosure and privilege escalation.

A. Setup

  • The experiments used a commodity DDR3 machine and a Fil-C 0.679 victim; the reproducible results delivered the single-bit flip out of band to isolate metadata corruption from flip throughput.This path required no root, hugepages, or special DRAM, only permission to ptrace a forked child; physical delivery was evaluated separately on a TRR-equipped DDR4 machine.Source: A. Setup · p. 8

B. Confirming the layout and the flip effect

  • A 256-byte object’s bounds were 256 bytes apart, with its upper bound stored at payload−16; flipping bit 7 expanded the reported length to 384 bytes.The attacker chose the smallest currently-zero bit that covered the intended target, yielding the minimal necessary expansion.Source: B. Confirming the layout and the flip… · p. 8

C. Real-runtime bypass and control

  • With the flip, the real Fil-C runtime permitted previously out-of-bounds accesses in every tested scenario; without it, the same accesses triggered a hard panic and killed the victim.The no-flip control confirms the accesses were genuinely out of bounds and that metadata corruption removed the protection.Source: C. Real-runtime bypass and control · p. 8, Table III · p. 8

D. Case studies

  • Four ordinary C victims compiled under Fil-C were defeated by one bit flip in the target object’s upper-bound word, with cross-object targets placed immediately above it.The victims relied on InvisiCaps for spatial safety and cooperated with the attacker only through a small shared handshake region; the runtime itself decided whether accesses were permitted.Source: secret · p. 8

generic,

  • In the generic victim, one flip converted an intact 256-byte object into a forward out-of-bounds read/write window: the runtime permitted both accesses, while the intact bound caused a hard panic.The victim read and wrote the first byte past the original end.Source: secret · p. 8

secret,

  • In the secret case, the corrupted bound let the target’s capability read across the allocation boundary and disclose a confidential token in the adjacent object.The disclosure relied on the corrupted upper bound, not another memory error in the victim.Source: secret · p. 8

authflag:

  • In the authflag case, one flip let an out-of-bounds write change a neighboring guest session’s is_admin field from 0 to 1, causing the privilege check to elevate the guest to admin.The check read the changed field through the neighboring object’s own intact capability.Source: authflag · p. 8
  • The SQLite-based multi-tenant victim showed the same flaw in a service built around unmodified SQLite: a guest handler’s corrupted bound enabled disclosure of an adjacent tenant’s database-stored admin API key.The vulnerability arose from metadata corruption in the experimental service, not SQLite; the library was compiled as its shipped 9 MB amalgamation.Source: authflag · pp. 8–9

E. Size-class generality · F. Physical feasibility of delivery · G. Physical feasibility under in-DRAM mitigation: DDR4

The paper shows that Fil-C bypasses persist across allocator size classes and can be delivered through fully physical Rowhammer chains on both DDR3 and TRR-equipped DDR4. In these experiments, the flip primitive and runtime consequence are reliable once a usable flip lands, while placement in the exact live metadata word is probabilistic.

E. Size-class generality

  • All three bypasses again succeeded with 512-byte targets, and generic and authflag required minimum flip bit k = 6 (+64 B), down from k = 7 for 256-byte targets.The 512-byte allocation is exact-fit, with the secondary payload starting 16 B past the original upper bound; the minimum flip bit tracks class gap rather than raw object size.Source: E. Size-class generality · p. 9

F. Physical feasibility of delivery

  • On DDR3, a fully physical campaign delivered a usable flip and completed the bypass in roughly two minutes, after control-verified flips were observed in both polarities.The end-to-end path used page-frame grooming and no out-of-band assist; a real 0→1 flip in a live victim’s upper-bound word enabled out-of-bounds reads and writes.Source: F. Physical feasibility of delivery · p. 9

End-to-end result:

  • For both DDR3 and DDR4, exact-word placement is the probabilistic binding stage; templating and the Fil-C consequence are reliable once a usable flip lands.DDR3 placement requires a valid 0→1 increase in the bound that reaches the target data; DDR4 additionally requires zone-locality, while VRT contributes variability.Source: F. Physical feasibility of delivery · p. 9, End-to-end result · p. 10

G. Physical feasibility under in-DRAM mitigation: DDR4

  • The DDR4 validation exercised templating, TRR-aware delivery, and the Fil-C consequence entirely physically on a commodity single-channel desktop with one non-ECC DDR4 DIMM.The module ran at the standard refresh rate and had in-package TRR that could not be disabled; vendor and platform details were withheld under the disclosure policy.Source: G. Physical feasibility under in-DRAM… · pp. 9–10

Targeting under TRR:

  • DDR4 targeting used an empirically derived same-bank neighbour oracle, wide many-sided hammering to evade TRR sampling, and no-hammer controls to reject retention noise.Variable-retention-time windows made cells susceptible only transiently, yet self-templating reliably produced control-verified hammer-induced flips in both directions.Source: Targeting under TRR · p. 10

Grooming under TRR: a zone-locality condition:

  • DDR4 frame grooming required a scout allocation to identify the victim’s active memory zone, then templating and donation confined to that zone.Frames donated from another zone cannot be reused by the victim, regardless of repeated grooming cycles.Source: Grooming under TRR: a zone-locality… · p. 10

End-to-end result:

  • Across four DDR4 case studies, fully physical attacks enabled generic out-of-bounds access, secret-token disclosure, authflag privilege escalation, and kv vault leakage in 10–35 minutes per run.The real Fil-C runtime permitted the accesses after hammer-induced flips reached live InvisiCap upper-bound words; outcomes were directly observed through a handshake channel.Source: End-to-end result · p. 10

Why this result matters beyond DDR3 alone:

  • On the tested TRR-equipped DDR4 module, TRR did not prevent a hammer-induced flip from reaching live bounds metadata, and a usable flip defeated the runtime regardless of delivery method.The paper demonstrates this physically on pre-TRR DDR3 and TRR-equipped DDR4, and deterministically across all four case studies.Source: Why this result matters beyond DDR3… · p. 10

VII. DISCUSSION … C. Limitations

Fil-C’s memory-safety proof assumes DRAM faithfully stores values, so an undetected Rowhammer corruption of metadata can defeat the runtime. The discussion explains how FUGC affects attack placement and limits the scope and delivery conditions of the evaluation.

A. Why the attack works

  • Rowhammer silently violates Fil-C’s assumption that metadata remains immutable, allowing one corrupted physical cell to collapse its otherwise valid C-memory-model safety proof.Every dereference is instrumented and bounds-checked, but the corruption raises no signal or machine check and touches no target cell through a read or write instruction.Source: A. Why the attack works · p. 10

B. FUGC interaction

  • FUGC’s non-moving collector leaves live objects and their InvisiCap cells in place, so the attacker need not contend with compaction relocating groomed metadata.Retaining live references prevents reclamation and slot reuse; the evaluation observed no failures from relocation or reuse.Source: B. FUGC interaction · pp. 10–11
  • A moving collector would reintroduce relocation risk and require explicit pinning or renewed grooming after collection, whereas FUGC requires neither.Reclamation is the remaining collector-level concern because a freed object’s slot may be reused.Source: B. FUGC interaction · p. 11

C. Limitations

  • On two lab machines, the physical attack chain induced genuine flips in attacker memory and flipped a victim’s live InvisiCap upper-bound word, bypassing the runtime.The DDR4 TRR-equipped system reproduced all four case studies using a fully physical attack chain.Source: C. Limitations · p. 11
  • The case-study evaluation modeled delivery out-of-band for determinism, while the physical primitive was established prior work on which the result builds.The integrated physical path remains probabilistic from run to run.Source: C. Limitations · p. 11
  • On DDR4, delivery is further constrained by TRR and whether the donated frame belongs to the victim’s current allocator zone, but TRR did not prevent delivery on the tested module.These constraints affect delivery, not the generation-independent consequence of a flip reaching metadata.Source: C. Limitations · p. 11
  • The evaluation used 256- and 512-byte victim objects and Fil-C 0.679’s inline-header layout, while other size classes or future versions may place headers differently.The exposure remains structural because the bounds stored in DRAM are unauthenticated.Source: C. Limitations · p. 11

VIII. RELATED WORK … IX. MITIGATIONS

Related work shows that software and hardware memory-safety mechanisms can leave security-critical state in DRAM, where faults may undermine their guarantees. The paper distinguishes Fil-C-specific detection measures from general Rowhammer defenses and identifies costs and concurrency constraints for both.

A. Software and hardware memory safety.

  • SoftBound/CETS, AddressSanitizer, Arm MTE [4], and related hardware primitives leave metadata or security-critical state in DRAM vulnerable to out-of-band faults.SoftBound/CETS use disjoint per-pointer metadata and AddressSanitizer uses red-zones and shadow memory; MPK, POE/POE2, and vMTE control access or colouring but do not authenticate DRAM state.Source: A. Software and hardware memory safety · p. 11
  • CHERI tags prevent software from forging capabilities, but a fault that changes addressable encoding bits while leaving a tag set has no general detection guarantee.A tag-storage 0→1 fault is implementation-dependent and unevaluated; whether an encoding flip yields a more-permissive well-formed capability must be established experimentally, so the Fil-C result does not transfer as a corollary.Source: A. Software and hardware memory safety · p. 11

B. Rowhammer consequences

  • A single flip can turn a valid capability word into another valid, still-canonical word encoding a wider bound accepted by the runtime, showing software memory safety silently inherits an unstated DRAM-integrity assumption.Source: B. Rowhammer consequences · p. 12

C. Rowhammer techniques and defences.

  • Rowhammer techniques and defenses across DRAM generations support the conditional premise that usable flips are attainable, while the paper does not claim to extend delivery research.Examples include TRRespass, Blacksmith, RowPress, Half-Double, ZenHammer, and ECC bypasses,; DRAMA supports selecting same-bank aggressors.Source: C. Rowhammer techniques and defences · p. 12

IX. MITIGATIONS

  • Fil-C-specific defenses authenticate or replicate in-DRAM bounds to make flips detectable, while general Rowhammer defenses impede fault delivery for any scheme storing metadata in DRAM.The paper frames preventing Rowhammer as a hardware-level task, not Fil-C’s burden.Source: §IX · p. 12

Cost and concurrency:

  • Authenticating or replicating bounds adds memory, cache pressure, and computation; per-use checks prevent silent use but charge every dereference, while periodic checks detect corruption later.For example, authentication once per FUGC sweep amortises cost but may leave the runtime honoring a corrupted bound until the next check.Source: Cost and concurrency · p. 12
  • Verify-then-use checks leave a TOCTTOU window; closing it requires atomic verify-and-use or consuming the verified snapshot, with protected state kept consistent during concurrent FUGC operation.FUGC traverses and rewrites free-list state, making consistency among protected words, replicas or authenticators, and keys nontrivial.Source: Cost and concurrency · p. 12

A. Fil-C-specific: authenticate the metadata · B. General Rowhammer defences: raise the delivery bar

The section presents metadata authentication and redundant bound storage as ways to detect Rowhammer corruption, while noting their implementation costs and deployment constraints. It also discusses delivery-side defences that make corruption harder to deliver without protecting a runtime after corrupted metadata is consumed.

Keyed capability MACs:

  • A keyed capability MAC stores MACK(lower ∥ upper) at allocation and verifies it before use, causing a dereference to fault if the upper bound is flipped.Arm Pointer Authentication Codes used as the authenticator are speculatively forgeable, and a MAC over bounds inherits that issue.Source: Keyed capability MACs · p. 12
  • MAC deployment requires changing Fil-C’s fully occupied 16-byte header, protecting the key outside hammerable DRAM, and accounting for verification overhead.The header contains an 8-byte upper bound and 8-byte aux word; SipHash verification costs tens of cycles per check, though FUGC sweeps can amortise it at the cost of delayed detection.Source: Keyed capability MACs · pp. 12–13

redundant bound storage.

  • Redundant bound storage keeps two copies at physically distant locations and compares them at each use, increasing the cost of exploiting a flip.It adds a cache miss per dereference and doubles bound footprint; replicas must stay atomically consistent across updates and FUGC to avoid spurious faults.Source: Keyed capability MACs · p. 13

A runnable check:

  • Under the same single-bit flip, the Fil-C baseline silently accepts the corrupted bound, while keyed MAC and redundant-copy variants fault.The self-contained check reproduces the Fil-C 0.679 inline-header layout and compares these variants.Source: redundant bound storage · p. 13, A runnable check · p. 13

B. General Rowhammer defences: raise the delivery bar

ECC memory:

  • SECDED ECC corrects isolated single-bit errors, but does not categorically prevent crafted multi-bit patterns; ECC makes corruption harder to deliver, not safer to consume.DDR4 in-DRAM TRR did not prevent delivery on either non-ECC lab machine; enterprise Chipkill raises the bar but was not evaluated and does not guarantee against multi-bit silent corruption.Source: ECC memory · p. 13
  • Physical row isolation prevents disturbance from reaching metadata, while blocking clflush raises hammering costs but does not eliminate attacks.Software isolation approaches add memory and performance overheads and are not widely deployed on commodity Linux; JavaScript attacks can hammer without clflush,.Source: ECC memory · p. 13

X. CONCLUSION · XI. ETHICS CONSIDERATIONS

The paper shows that Rowhammer-induced corruption of Fil-C’s unauthenticated bounds metadata can defeat its spatial-safety guarantee, and describes the study’s safety precautions and disclosure process.

X. CONCLUSION

  • A single Rowhammer bit flip in Fil-C 0.679’s unauthenticated bounds word silently widened an object’s range, enabling four end-to-end safety-bypass case studies.The authors also demonstrated a hammer-induced metadata flip on susceptible DDR3 and on a tested TRR-equipped DDR4 module; the claim is conditional on delivering a usable flip to a live object’s upper-bound word. In the no-flip control, the runtime hard-panicked as expected, while the bypass occurred without a panic, signal, or machine check.Source: §X · p. 13

XI. ETHICS CONSIDERATIONS

  • The authors followed NDSS guidelines and the Menlo Report principles of beneficence, respect for persons, and justice.Source: §XI · p. 14

No harm to third parties:

  • The authors state that experiments used only their lab machines and owned DRAM, with isolated, network-disconnected systems and no human, personal, or production data.They withheld the DDR3 and DDR4 platform and module identities pending coordinated vendor disclosure.Source: No harm to third parties · p. 14

Benign by design:

  • The proof-of-concept grants no capability beyond what its operator already has and includes no self-propagation, network component, or means to target unowned processes.Its deterministic path writes only to an operator-controlled forked child, and its bare-metal engine disturbs only DRAM the operator owns.Source: Benign by design · p. 14

Nature of the disclosed weakness:

  • The authors characterize the exposure as a structural consequence of unauthenticated bounds metadata in commodity DRAM, not an implementation defect removable by a point patch.They describe Fil-C’s storage choice as deliberate for ISA compatibility and complete checking on stock CPUs, and say they introduce no new or faster flip-induction method.Source: Nature of the disclosed weakness · p. 14

Responsible disclosure:

  • The authors notified the Fil-C maintainer and affected DRAM manufacturers, then pursued CERT/CC coordination before planning dated advisories and public disclosure.After contacting the maintainer and one manufacturer on 27 July 2026 without response, they filed with CERT/CC on 12 August; CERT/CC declined coordination and a CVE on 14 August, and the authors withheld module identities pending the disclosure window.Source: Responsible disclosure · p. 14
Loading 2610.33748v1…