A recurring challenge in modern microarchitectural attacks is controlling or finding where sensitive data resides in physical memory. Rowhammer requires precisely positioning sensitive data, such as page tables, in vulnerable DRAM rows to trigger bit flips. Spectre-style attacks, on the other hand, depend on identifying where secrets are stored in memory in order to leak them via speculative execution.
Traditionally, this has been tackled using ad hoc methods, such as spraying, large-scale scanning, or other imprecise heuristics. These approaches are slow, fragile, and often inaccurate. In many cases, it’s the reliability of these techniques, not the actual exploit, that becomes the bottleneck.
Rubicon changes this. Rather than treating memory massaging as a means to an end, it approaches it as a core problem with a clean, robust, and general-purpose solution.
How Rubicon Works
At the heart of Rubicon lies a simple yet powerful observation: While the behavior of the Linux memory allocator might appear random, it is actually governed by deterministic rules. This allows attackers to anticipate where the next allocation will be served from and prepare the allocator’s state so that it returns memory under their control. The result is precise, reliable massaging.
To achieve this, Rubicon combines three low-level mechanisms:
1. PCP Evict: Most allocations are served from fast per-CPU pages (PCP) lists, , which are not directly manipulable. Rubicon floods a single PCP list to force the kernel into rebalancing, which drains the other PCP lists. This makes subsequent allocations fall back to the more controllable global free lists.
2. Block Merge: With allocations now coming from the free lists, Rubicon carefully prepares the allocator so that attacker-controlled pages are positioned exactly where the allocator will next allocate.
3. Migratetype Escalation: The Linux allocator segregates pages into migratetypes, such as MOVABLE, UNMOVABLE, and RECLAIMABLE, to improve memory management and reduce fragmentation. Some security-sensitive data structures, like page tables and kernel stacks, allocate exclusively from UNMOVABLE memory. Rubicon exploits an allocator optimization to reliably promote memory across migratetypes, enabling attacker memory to be placed into memory migratetypes typically reserved for privileged allocations.
 |
| Figure: Block Merge. We release the target block, initially split into pages (1), and push it onto the free lists by releasing additional memory (2). When the pages reach the free list (3), they are merged into a single block and moved to the head of the higher-order free list (4). |
Performance and Reliability
We developed a suite of microbenchmarks to independently validate each of its mechanisms under diverse conditions. We tested across a wide range of kernel versions (5.4.0-125 to 6.8.0-51) and background loads.
The results were consistent: Rubicon’s mechanisms achieved a 100% success rate across all tested scenarios. This level of reliability makes Rubicon a practical and powerful primitive, suitable not only for research but also for real-world exploitation.
What Does Rubicon Enable?
Rubicon isn’t just a theoretical construct; it is designed to be deployed in real-world microarchitectural exploits. By providing deterministic control over physical memory, it removes one of the key barriers that have limited the practicality of these attacks in the past.
Rowhammer
Rubicon brings precise memory massaging to Rowhammer, allowing attackers to place page tables in vulnerable DRAM rows without polluting adjacent memory with crash-prone kernel metadata. This enables the first 100% crashless Rowhammer attack. In over 240 attack runs on five TRR-protected DDR4 DIMMs, Rubicon achieved an 87.3% success rate without a single system crash. (Failures are due solely to the probabilistic nature of triggering a bit flip.) Even under sustained system load using stress-ng, the success rate remained effectively unchanged at 83.75%, demonstrating the robustness of Rubicon’s massaging mechanisms.
Transient-execution Attacks
Rubicon also significantly enhances transient-execution attacks like Spectre. Previously, these attacks required an imprecise, time-consuming phase to scan memory and locate files like /etc/shadow. Rubicon eliminates this step entirely. By deterministically placing the file at a known physical address, data leakage begins immediately. On an Intel i7-8700K, the leak is completed in just 9.5 seconds, a 284x speedup. On an AMD EPYC 7252, the leak completes in 27.9 seconds, providing a 6.8x speedup.
Mitigations
Rubicon exploits specific, deterministic behaviors in the Linux memory allocator. By targeting these behaviors directly, we propose a set of lightweight mitigations that block Rubicon’s mechanisms without significant performance overhead:
- Individual List Counters: Introduce per-list counters within each PCP list. This localizes allocation pressure and prevents a flooded PCP list from triggering global rebalancing that drains other PCPs.
- Batch Randomization: Introduce controlled randomness into allocator paths. This breaks the deterministic behavior Rubicon depends on, mitigating Block Merge.
- Secure Stealing Condition: Tighten migratetype promotion rules to prevent speculative movement of pages across migratetypes.
We implemented these mitigations in Linux 5.15 and evaluated them across diverse workloads, including Pmbench, UnixBench, and TensorFlow Lite. The changes fully neutralized Rubicon’s mechanisms with a measured performance overhead of less than 0.1%.
FAQs
Which Linux versions are vulnerable?
We validated Rubicon on kernels 5.4.0-125 up to 6.8.0-5, but all kernel versions relying on the Zoned Buddy Allocator are theoretically vulnerable.
What about other operating systems?
Rubicon is specifically designed for the Linux kernel. Other operating systems, such as FreeBSD, macOS, or Windows, utilize different memory allocators and are therefore not affected by Rubicon. However, the underlying principles of Rubicon could potentially be adapted to other systems with similar memory management strategies.
Does Rubicon also work inside virtual machines or public-cloud guests?
Conceptually, yes, as the primitives rely only on user-space syscalls. In practice, however, memory ballooning, memory-quota enforcement, and other hypervisor policies complicate the massaging sequence, so an attacker must adapt the recipe. The paper discusses these challenges (§10) and points out that allocator determinism remains despite virtualisation.
Paper and source code
Rubicon will be presented at IEEE’s European Symposium on Security and Privacy ‘25 (EuroS&P ‘25) in Venice, Italy. The paper can be found here. All of Rubicon’s source code can be found on GitHub.