Full Report
Introduction I’ve recently been researching Pixel kernel exploitation and as part of this research I found myself with an excellent arbitrary write primitive…but without a KASLR leak. As necessity is the mother of all invention, on a hunch, I started researching the Linux kernel linear mapping. The Linux Linear Mapping The linear mapping is a region in the kernel virtual address space that is a direct 1:1 unstructured representation of physical memory. Working with Jann, I learned how the kernel decided where to place this region in the virtual address space. To make it possible to analyze kernel internals on a rooted phone, Jann wrote a tool to call tracing BPF’s privileged BPF_FUNC_probe_read_kernel helper, which by design permits arbitrary kernel reads. The code for this is available here. The linear mapping virtual address for a given physical address is calculated by the following macro:
Analysis Summary
# Research: Defeating KASLR by Doing Nothing at All
## Metadata
- Authors: Seth Jenkins (with contributions acknowledged from "Jann")
- Institution: Project Zero / Google
- Publication: Project Zero Blog
- Date: 2025-Nov-03
## Abstract
This research investigates a vulnerability in the addressing mechanism of the Linux kernel, specifically on arm64 Android devices (like Google Pixels), which subverts the intended security benefits of Kernel Address Space Layout Randomization (KASLR). The core finding is that due to design choices related to memory hot-plugging support (`CONFIG_MEMORY_HOTPLUG=y`) and low virtual address space constraints on arm64, the **Linux kernel linear mapping**—which provides a direct 1:1 virtual-to-physical memory representation—is placed at a statically known virtual address range. Further compounding this, Pixel bootloaders notoriously load the kernel image at a fixed physical address. The combination of a statically known physical base address and a statically calculated virtual mapping allows an attacker with an arbitrary write primitive to calculate precise kernel virtual addresses without needing a traditional KASLR leak.
## Research Objective
The primary objective was to investigate methods for escalating privileges on Pixel devices when an attacker has obtained an arbitrary write primitive but lacks a viable Kernel Address Space Layout Randomization (KASLR) leak. This necessitated understanding how the Linux kernel maps physical memory into the virtual address space, particularly the linear mapping region.
## Methodology
### Approach
1. **Kernel Internals Research:** Investigating the structure and placement of the Linux kernel's linear mapping in the virtual address space on arm64 devices.
2. **Tool-Assisted Analysis:** Utilizing a specialized tool based on eBPF to read kernel internals required to calculate the mapping offset.
3. **Empirical Validation:** Reading exposed kernel symbols (`/proc/kallsyms`) and memory configuration (`/proc/iomem`) to confirm theoretical address calculations on a rooted device.
4. **Deductive Reasoning:** Combining the static location of the linear map with static kernel loading addresses to derive a predictable virtual address calculation.
### Dataset/Environment
- Rooted Google Pixel devices running Android on the arm64 architecture.
- The specific kernel configuration leading to the placement of the linear map (e.g., 39-bit virtual address space).
### Tools & Technologies
- **BPF (Berkeley Packet Filter):** Specifically leveraging the privileged `BPF_FUNC_probe_read_kernel` helper function via a custom tracing tool written by "Jann" to facilitate arbitrary kernel reads for analysis.
- Standard Linux tools for inspection (`grep`, shell utilities) used on the rooted device against `/proc/kallsyms` and `/proc/iomem`.
## Key Findings
### Primary Results
1. **Static Linear Mapping Base:** On arm64 systems supporting memory hot-plugging (like Android), the Linux kernel places the linear mapping region at a fixed virtual base address: `0xffffff8000000000` (`PAGE_OFFSET`). This offset is determined because the kernel prioritizes accommodating potential future physical memory expansion over randomizing the mapping's location.
2. **Static Kernel Physical Base:** Pixel bootloaders were found to load the kernel image to a statically known physical address (`0x80010000`), which is not randomized across reboots.
3. **KASLR Bypass (Effective):** The combination of a static physical base address and the static calculation formula for the linear mapping (`phys_to_virt(x) = ((x) - 0x80000000) | 0xffffff8000000000`) means that any kernel physical address is trivially convertible to its corresponding virtual address, bypassing the need for a KASLR leak entirely for exploitation.
### Supporting Evidence
- The value of `memstart_addr` (which defines `PHYS_OFFSET`) was statically observed as `0x80000000` using the BPF read tool.
- Logs show that the calculation for converting a physical address (`x`) to a linear map virtual address is fixed based on constants derived from the arm64 architecture configuration (39 bits).
- Examination of `/proc/iomem` confirms the kernel code and data occupy a fixed physical range starting at `0x80010000`.
### Novel Contributions
- Identifying that the engineering compromise made to support Linux memory hot-plugging functionally neutralizes the security benefit of linear map randomization on arm64 kernels.
- Demonstrating a reliable, KASLR-independent technique to resolve kernel virtual addresses on specific, widely deployed mobile platforms (Pixel devices) by exploiting the static kernel load address combined with the static linear mapping calculation.
## Technical Details
The linear mapping formula is given by:
$$\text{virt\_addr} = (( \text{phys\_addr} - \text{PHYS\_OFFSET} ) \mid \text{PAGE\_OFFSET})$$
On arm64 Android (CONFIG\_ARM64\_VA\_BITS=39):
* `PAGE_OFFSET` is $-(2^{39}) = 0\text{xffffff8000000000}$ (This forms the high bits of the kernel virtual address).
* `PHYS_OFFSET` (derived primarily from `memstart_addr`) is statically $0\text{x80000000}$.
Since both components are fixed, for any known physical address (like a symbol address in the kernel data section), an attacker can calculate the precise virtual address in the linear mapping region where the kernel's content resides.
## Practical Implications
### For Security Practitioners
This research significantly lowers the bar for local kernel exploitation on affected arm64 Android devices, even when traditional KASLR randomization is active or partially effective. An attacker only needs a single arbitrary write primitive and the ability to read a few key kernel symbols (e.g., from `/proc/kallsyms`) to proceed with exploitation without needing a vulnerability that leaks the base kernel address.
### For Defenders
The primary defensive insight is that KASLR alone is an insufficient mitigation against local exploitation chains based on an arbitrary write primitive, particularly on Linux kernels configured for memory hot-plug. Defenses must rely on finer-grained memory protection techniques beyond simple address randomization.
### For Researchers
This highlights the tension between system flexibility (like memory hot-plug) and security mitigation integrity. Researchers should focus on memory integrity controls (e.g., Pointer Authentication Codes or fine-grained read/write protection) rather than solely relying on address layout randomization for core kernel components.
## Limitations
- This specific bypass relies on the **combination** of the static linear map placement (an upstream kernel design choice) and the static kernel physical load address (a device-specific bootloader choice, common on Pixel).
- The report notes that side-channel attacks bypassing KASLR have not yet been observed in the wild on Android, implying KASLR still offers *some* protection against remote exploits relying on timing.
## Comparison to Prior Work
This work builds upon the general understanding that KASLR must not be solely relied upon. However, instead of relying on side-channel attacks or complex leakage primitives, this method exploits a static, fundamental mapping feature of the Linux kernel design itself, making the prerequisite for exploitation simpler (just an arbitrary write). It specifically contrasts with X86 KASLR exploitation, where the linear map randomization is often more robust.
## Future Work
- Urging Linux kernel developers to implement memory hot-plug support in a way that preserves linear map randomization entropy.
- Investigating whether other arm64 vendors besides Google employ static kernel loading addresses.
- Exploring concrete mitigation steps, such as randomizing the physical page allocation entropy or improving virtual address space utilization on arm64.
## References
- Linux kernel commit [1db780bafa4c] (related to termination of virtual address randomization for the linear map).
- Kernel documentation on arm64 booting regarding random physical address placement.
- Prior report on the state of X86 KASLR.
- Research issue regarding BPF arbitrary read tool implementation.
- Research issue regarding static kernel load address on Pixel.