Linux arm64 Static Linear Map KASLR Bypass

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Visão Geral

Os kernels Android compilados para arm64 quase universalmente ativam CONFIG_ARM64_VA_BITS=39 (paginação em 3 níveis) e CONFIG_MEMORY_HOTPLUG=y. Com apenas 512 GiB de espaço virtual do kernel disponível, os desenvolvedores do Linux escolheram ancorar o linear map no menor VA de kernel possível, para que RAM adicionada via hot-plug possa simplesmente estender o mapeamento para cima. Desde o commit 1db780bafa4c, arm64 nem tenta mais randomizar esse posicionamento, o que significa:

  • PAGE_OFFSET = 0xffffff8000000000 está definido na compilação.
  • PHYS_OFFSET é obtido a partir do memstart_addr exportado, que em dispositivos Android stock é efetivamente constante (0x80000000 hoje).

Como consequência, cada página física tem um endereço virtual determinístico no linear-map que é independente do KASLR slide:

#define phys_to_virt(p) (((unsigned long)(p) - 0x80000000UL) | 0xffffff8000000000UL)

Se um atacante puder descobrir ou influenciar um endereço físico (kernel object, PFN from /proc/pagemap, ou mesmo uma página controlada pelo usuário), eles passam a saber instantaneamente o endereço virtual correspondente no kernel, sem leaking do mapeamento primário randomizado do kernel.

Lendo memstart_addr e confirmando a transformação

memstart_addr é exportado em /proc/kallsyms e pode ser lido em dispositivos rooted ou via qualquer kernel-read primitive. Project Zero used Jann Horn’s tracing-BPF helper (bpf_arb_read) to dump it directly:

grep memstart /proc/kallsyms
# ... obtains memstart_addr virtual address
./bpf_arb_read <addr_of_memstart_addr> 8

The bytes 00 00 00 80 00 00 00 00 confirm memstart_addr = 0x80000000. Once PAGE_OFFSET and PHYS_OFFSET are pinned, the arm64 linear map is a static affine transform of any physical address.

Deriving stable .data addresses on devices with a fixed kernel physbase

Many Pixels still decompress the kernel at phys_kernel_base = 0x80010000 on every boot (visible in /proc/iomem). Combining that with the static transform yields cross-reboot-stable addresses for any data symbol:

  1. Record the randomized kernel virtual address of _stext and of your target symbol from /proc/kallsyms (or from the exact vmlinux).
  2. Compute the offset: offset = sym_virt - _stext_virt.
  3. Add the static boot-time physbase: phys_sym = 0x80010000 + offset.
  4. Convert to a linear-map VA: virt_sym = phys_to_virt(phys_sym).

Example (modprobe_path on a Pixel 9): offset = 0x1fe2398, phys = 0x81ff2398, virt = 0xffffff8001ff2398. After multiple reboots, bpf_arb_read 0xffffff8001ff2398 returns the same bytes, so exploit payloads can treat 0xffffff8000010000 as a synthetic, non-randomized base for all .data offsets.

This mapping is RW, so any primitive that can place attacker data in kernel virtual space (double free, UAF, non-paged heap write, etc.) can patch credentials, LSM hooks, or dispatch tables without ever leaking the true KASLR slide. The only limitation is that .text is mapped non-executable in the linear map, so gadget hunting still requires a traditional leak.

PFN spraying when the kernel physbase is randomized

Vendors such as Samsung randomize the kernel load PFN, but the static linear map is still abusable because PFN allocation is not fully random:

  1. Spray user pages: mmap() ~5 GiB, touch every page to fault it in.
  2. Harvest PFNs: read /proc/pagemap for each page (or use another PFN leak) to collect the backing PFN list.
  3. Repeat and profile: reboot, rerun 100×, build a histogram showing how often each PFN was attacker-controlled. Some PFNs are white-hot (allocated 100/100 times shortly after boot).
  4. Convert PFN → kernel VA:
  • phys = (pfn << PAGE_SHIFT) + offset_in_page
  • virt = phys_to_virt(phys)
  1. Forge kernel objects in those pages and steer victim pointers (UAF, overflow, etc.) to the known linear-map addresses.

Because the linear map is identity-mapped RW memory, this technique lets you place fully attacker-controlled data at deterministic kernel VAs even when the real kernel base moves. Exploits can prebuild fake file_operations, cred, or refcount structures inside the sprayed pages and then pivot existing kernel pointers into them.

Practical workflow for arm64 Android exploits

  1. Info gathering
  • Root or use a kernel read primitive to dump memstart_addr, _stext, and the target symbol from /proc/kallsyms.
  • On Pixels, trust the static physbase from /proc/iomem; on other devices, prepare the PFN profiler.
  1. Address calculation
  • Apply the offset math above and cache the resulting linear-map VAs in your exploit.
  • For PFN spraying, keep a list of “reliable” PFNs that repeatedly land in attacker memory.
  1. Exploit integration
  • When an arbitrary write is available, directly patch targets such as modprobe_path, init_cred, or security ops arrays at the precomputed addresses.
  • When only a heap corruption exists, craft fake objects in the known-supervised pages and repoint victim pointers to those linear-map VAs.
  1. Verification
  • Use bpf_arb_read or any safe read primitive to sanity-check that the computed address contains the expected bytes before destructive writes.

This workflow eliminates the KASLR-leak stage for data-centric kernel exploits on Android, which drastically lowers exploit complexity and improves reliability.

References

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks