A tool for inferring the Linux kernel base address and physical memory layout as an unprivileged local user, for the purpose of bypassing Kernel Address Space Layout Randomization (KASLR). An orchestrator discovers and runs standalone leak components, then validates, cross-references, and summarizes the results with section-aware consensus analysis.

Supports:

• x86 (i386+, amd64)
• ARM (armv6, armv7, armv8)
• MIPS (mipsbe, mipsel, mips64el)
• PowerPC (ppc, ppc64)
• RISC-V (riscv32, riscv64)
• LoongArch (loongarch64)

• Usage
  • Example Output
• Building
• Configuration
• Architecture and Design
  • Component model
  • Phases
  • Cross-section derivation
    • Component-level derivation
    • Orchestrator derivation rules
  • Kernel version detection
  • Writing a component
    • Tagged line protocol
    • Sections
    • Labels
    • Exit code convention
    • Minimal component
    • API reference
• KASLR and Kernel Memory Layout
  • Function Offsets
  • Function Granular KASLR (FG-KASLR)
  • Linux KASLR History and Implementation
    • Default text base and KASLR alignment
  • Physical and Virtual KASLR
  • Kernel Sections
  • Virtual Memory Split (vmsplit)
• KASLR Bypass Techniques
  • Filesystem Leaks
    • System Logs
    • DebugFS
    • Procfs and Sysfs
    • Boot Configuration
  • Side-Channels
  • Syscall and Interface Leaks
  • Brute Force
  • Weak Entropy
  • Patched Kernel Bugs
  • Arbitrary Read
• License

sudo apt install libc-dev make gcc binutils git
git clone https://github.com/bcoles/kasld
cd kasld
make run

Each component in the src/ directory is a standalone leak component using a different technique to retrieve or infer kernel addresses. The kasld orchestrator discovers and executes all components, displays results in real-time, and produces a section-aware summary with validated addresses grouped by kernel section (text, modules, direct map, etc).

After building, the build/<arch>/ directory is self-contained and can be deployed to a target system:

build/<arch>/
  kasld              <- run this
  components/        <- leak components

Modern fully-patched systems with kernel.dmesg_restrict=1, kernel.kptr_restrict=1, and kernel.perf_event_paranoid=2 (or higher) are expected to return limited results. For testing purposes, the extra/weaken-kernel-hardening script can temporarily relax these settings (requires root).

The following is example output from a default Debian 13 (x86-64) system:

     ▄█   ▄█▄    ▄████████    ▄████████  ▄█       ████████▄
    ███ ▄███▀   ███    ███   ███    ███ ███       ███   ▀███
    ███▐██▀     ███    ███   ███    █▀  ███       ███    ███
   ▄█████▀      ███    ███   ███        ███       ███    ███
  ▀▀█████▄    ▀███████████ ▀███████████ ███       ███    ███
    ███▐██▄     ███    ███          ███ ███       ███    ███
    ███ ▀███▄   ███    ███    ▄█    ███ ███▌    ▄ ███   ▄███
    ███   ▀█▀   ███    █▀   ▄████████▀  █████▄▄██ ████████▀
    ▀                                   ▀ v0.1.0

Kernel release:               6.12.38+deb13-amd64
Kernel version:               #1 SMP PREEMPT_DYNAMIC Debian 6.12.38-1 (2025-07-16)
Kernel arch:                  x86_64

kernel.kptr_restrict:         0
kernel.dmesg_restrict:        1
kernel.panic_on_oops:         0
kernel.perf_event_paranoid:   3

Readable /var/log/dmesg:      no
Readable /var/log/kern.log:   no
Readable /var/log/syslog:     no
Readable DebugFS:             no
Readable /boot/System.map:    yes
Readable /boot/config:        yes

Running 49 components...
[####################] 100%  49/49  11.1s

========================================
 Results
========================================

  Kernel text (virtual)     0xffffffffa7a00000  (1 source)
  Physical DRAM             0x0000000000000000 - 0x0000000080000000  (2.0 GiB, 7 sources)
  Physical MMIO             0x00000000000c0000 - 0x00000000febfffff  (4.0 GiB, 2 sources)

----------------------------------------
KASLR analysis:
  Virtual text base:    0xffffffffa7a00000
  Default text base:    0xffffffff81000000
  KASLR slide:          +648019968 (618.0 MiB)
  KASLR text entropy:   8 bits (504 slots of 0x200000)
  Observed slot index:  309 / 504

----------------------------------------
Virtual memory layout (decoupled):

  0xffffffffffffffff
  +------------------------------------------------------------------+
  |  modules                                                         |
  |  (no leak)                                                       |
  +------------------------------------------------------------------+
  0xffffffffc0000000
  +------------------------------------------------------------------+
  |  kernel text                                                     |
  |    0xffffffffa7a00000                                            |
  +------------------------------------------------------------------+
  0xffffffff80000000
  +------------------------------------------------------------------+
  |                                                                  |
  |  ...  128.0 TiB                                                  |
  |                                                                  |
  +------------------------------------------------------------------+
  |  direct map                                                      |
  |  (no leak)                                                       |
  +------------------------------------------------------------------+
  0xffff800000000000

Physical memory layout:

  0x00000000febfffff
  +------------------------------------------------------------------+
  |  0x00000000febfffff  [mmio] sysfs_pci_resource:hi                |
  |  0x0000000080000000  [dram] proc-zoneinfo:hi                     |
  |  0x000000007fffffff  [dram] sysfs_firmware_memmap:hi             |
  |  0x000000007c944000  [dram] sysfs_vmcoreinfo                     |
  |  0x00000000000c0000  [mmio] sysfs_pci_resource:lo                |
  |  0x0000000000001000  [dram] proc-zoneinfo:lo                     |
  |  0x0000000000000000  [dram] sysfs_firmware_memmap:lo             |
  +------------------------------------------------------------------+
  0x0000000000000000

A compiler which supports the _GNU_SOURCE macro is required due to use of non-portable code (MAP_ANONYMOUS, getline(), popen(), ...).

make              # build kasld + components
make run          # build and run
make test         # build and run unit tests
make cross        # cross-compile for all supported architectures
make install      # install to /usr/local (PREFIX=/usr/local)
make uninstall    # remove installed files
make clean        # remove build directory
make help         # show all targets and options

Command-line options:

-j, --json      Machine-readable JSON output
-1, --oneline   Single-line summary output
-m, --markdown  Markdown table output
-c, --color     Colorize text output (auto-detected for TTYs)
-v, --verbose   Show component output
-V, --version   Print version and exit
-h, --help      Show this help

KASLD can be cross-compiled with make by specifying the appropriate compiler (CC). Static linking is applied automatically when cross-compiling:

make CC=aarch64-linux-musl-gcc

Build all supported cross-compilation targets (toolchains must be in PATH):

make cross

Architecture-specific kernel memory layout constants are defined in kasld.h. The default values should work on all systems, but may need to be adjusted for very old kernels, embedded devices, or systems with unusual configurations.

The orchestrator automatically aligns leaked addresses to KERNEL_ALIGN boundaries and adjusts for TEXT_OFFSET. If a component detects a non-default PAGE_OFFSET at runtime (e.g. on a 32-bit system with a 2G/2G vmsplit), the orchestrator adjusts all layout boundaries before validation.

Refer to the comment headers in kasld.h for documentation of each configuration option.

KASLD's architecture is a simple contract: each component is a standalone executable that probes one data source and prints tagged lines to stdout. The orchestrator discovers, runs, and post-processes components automatically — no registration, no linking, no Makefile changes.

The orchestrator runs each component as an isolated child process:

1. fork() + execl() — the component runs in its own process group
2. stdout and stderr are merged into a single pipe back to the orchestrator
3. The orchestrator reads lines from the pipe, capturing tagged lines as results and (in verbose mode) printing all output
4. A per-component timeout (default: 30 seconds, configurable via --timeout) kills the component and its children if it does not exit in time
5. The exit code signals the component's relationship with its data source (see Exit code convention below). Tagged lines emitted before exit (or timeout) are always captured.

This model means a component that segfaults, hangs, or exits with an error does not affect other components or the orchestrator.

Tagged lines are parsed, aligned to the architecture's KERNEL_ALIGN boundary, validated against expected address ranges, assigned a method label (exact, parsed, timing, or heuristic), and grouped by section for consensus analysis. Components do not need to align addresses or validate ranges — report the raw leaked value and the orchestrator handles the rest.

Components run in three phases, determined by name:

The orchestrator runs apply_layout_adjustments() between each phase, propagating PAGE_OFFSET discoveries and revalidating all prior results. Phase 3 is skipped entirely when KASLR is detected as disabled.

New components are placed in Phase 2 by default — no configuration needed. To assign a component to Phase 1 or Phase 3, add its name to the phase_discovery[] or phase_probing[] array in orchestrator.c.

The kernel virtual address space contains distinct sections (text, modules, direct map) at different address ranges. On some architectures these are at fixed offsets from each other (coupled), so a leak from one section can derive addresses in another. KASLD exploits this at two levels: components can emit derived results directly, and the orchestrator derives centrally after collecting all results.

Components that leak a physical address can convert it to a direct-map virtual address using phys_to_virt(), guarded by #if !PHYS_VIRT_DECOUPLED so the derivation is compiled out on decoupled architectures (x86_64, arm64, RISC-V 64-bit). This produces an additional data point alongside the raw physical result.

The orchestrator implements cross-section derivation rules in compute_derived_addrs(). All derived addresses are aligned to KERNEL_ALIGN (e.g., 2 MiB on x86_64).

On coupled architectures (x86_32, arm32, MIPS, PowerPC, LoongArch, riscv32), the KASLR slide is a single offset applied uniformly, so a single address from any section is sufficient to derive all others:

PAGE_OFFSET, PHYS_OFFSET, and TEXT_OFFSET are compile-time constants (or runtime-detected in the case of a non-default vmsplit).

On decoupled architectures (x86_64, arm64, riscv64), physical and virtual addresses are randomized independently, so physical results cannot derive virtual text. The orchestrator prints a note when physical results exist that would have been derivable on a coupled system.

RISC-V64 is a special case among decoupled architectures: its module region is anchored to the kernel image, so module addresses provide an additional derivation path:

When both a physical DRAM address and a module address are available, the orchestrator cross-references them: if the physically-derived text base falls within the module-derived range, it is emitted as a high-confidence result.

Some techniques (e.g., EntryBleed) have been mitigated in specific mainline kernel releases. It would seem natural to check uname -r and skip components that target patched vulnerabilities.

KASLD deliberately does not do this. Distribution kernels (Ubuntu, Debian, RHEL, SUSE, etc.) backport security fixes extensively, and their version numbers do not correspond to the mainline release where a fix appeared:

• Ubuntu ships 4.4.0-xxx and 4.15.0-xxx LTS kernels that contain backported fixes from mainline 5.x and 6.x.
• RHEL ships 3.10.0-xxx kernels with fixes from mainline 4.x and 5.x.
• A kernel reporting 6.8.0 may lack a fix from mainline 6.3, or include a fix from mainline 6.12, depending on the distributor.

Version-based gating would be wrong in both directions: skipping a technique on a kernel that is actually vulnerable (false negative), or running a technique on a kernel that has already been patched (false positive).

Instead, KASLD treats each component as its own detector. Components probe the actual kernel — they either produce a result or they don't. Side-channel components that target patched vulnerabilities will time out (bounded by --timeout, default 30 seconds) or exit with no output, which the orchestrator handles gracefully. Filesystem-based components that lack access typically fail in under a second.

This design means KASLD is correct on any kernel — mainline, distro, custom, or embedded — without maintaining per-component version ranges that would be inaccurate for most real-world deployments.

Components communicate results to the orchestrator via tagged lines on stdout:

<type> <section> <addr> <label>

Example output from a component:

[.] trying /proc/kallsyms ...
V text 0xffffffff81000000 proc-kallsyms

The orchestrator ignores any line that does not begin with V, P, or D followed by a space. This means components can freely print diagnostic messages (progress, errors, explanations) to stdout — only tagged lines are captured as results.

A component may emit zero, one, or multiple tagged lines. The orchestrator processes each independently.

The label field identifies the source of the result. Convention:

• Simple label: the component name (proc-kallsyms, sysfs_vmcoreinfo)
• Qualified label: component:qualifier when a component emits multiple results from different derivations (sysfs_vmcoreinfo:directmap)
• Special labels: default:text (default kernel text address), default:unsupported (KASLR not supported on this architecture)

Components signal their outcome to the orchestrator via exit code:

The orchestrator classifies each component's outcome using this priority:

1. SUCCESS — component emitted at least one tagged line
2. TIMEOUT — component was killed by the timeout
3. ACCESS_DENIED — exit code 77
4. UNAVAILABLE — exit code 69
5. NO_RESULT — ran successfully but found nothing

The exit code answers "what was your relationship with your data source?" — not "did you find results". A component that accessed its data source and found no matching data should exit 0, not 69 or 77. The orchestrator already knows whether results were found from the tagged output.

The constants are defined in src/include/kasld_internal.h and follow the <sysexits.h> convention (EX_UNAVAILABLE = 69, EX_NOPERM = 77).

// src/components/my-leak.c
#include "include/kasld.h"
#include <stdio.h>
#include <stdlib.h>

int main(void) {
  unsigned long addr;

  /* ... probe a data source ... */
  addr = 0; /* replace with actual leak logic */

  if (!addr) {
    printf("[-] no kernel address found via my-leak\n");
    return 0;
  }

  printf("leaked kernel text address: 0x%lx\n", addr);
  kasld_result(KASLD_ADDR_VIRT, KASLD_SECTION_TEXT, addr, "my-leak");
  return 0;
}

Place the file in src/components/. Run make — the build system automatically discovers all .c files in that directory and compiles each into a standalone binary under build/<arch>/components/. No Makefile edits required.

The component can also be run directly:

$ ./build/x86_64-linux-musl/components/my-leak
leaked kernel text address: 0xffffffff81000000
V text 0xffffffff81000000 my-leak

Components that leak a physical address should also emit a derived direct-map virtual address on coupled architectures:

kasld_result(KASLD_ADDR_PHYS, KASLD_SECTION_DRAM, phys, "my-leak");

#if !PHYS_VIRT_DECOUPLED
unsigned long virt = phys_to_virt(phys);
kasld_result(KASLD_ADDR_VIRT, KASLD_SECTION_DIRECTMAP, virt,
             "my-leak:directmap");
#endif

The #if guard compiles out the derivation on decoupled architectures (x86_64, arm64, RISC-V 64-bit) where physical addresses cannot reveal virtual text. See Cross-section derivation for details.

The complete component API spans two headers: src/include/kasld.h (results, address layout) and src/include/kasld_internal.h (exit codes).

As the entire kernel code text is mapped with only the base address randomized, a single kernel pointer leak can be used to infer the location of the kernel virtual address space and offset of the kernel base address.

Offsets to useful kernel functions (commit_creds, prepare_kernel_cred, etc) from the base address can be pre-calculated on other systems with the same kernel - an easy task for publicly available kernels (ie, distro kernels).

Function offsets may also be retrieved from various file system locations (/proc/kallsyms, vmlinux, System.map, etc) depending on file system permissions. jonoberheide/ksymhunter automates this process.

Function Granular KASLR (aka "finer grained KASLR") patches for the 5.5.0-rc7 kernel were proposed in February 2020 (but have not been merged as of 2026-01-01).

This optional non-mainline mitigation "rearranges your kernel code at load time on a per-function level granularity" and can be enabled with the CONFIG_FG_KASLR flag.

FG-KASLR ensures the location of kernel and module functions are independently randomized and no longer located at a constant offset from the kernel .text base.

On systems which support FG-KASLR patches (x86_64 from 2020, arm64 from 2023), this makes calculating offsets to useful functions more difficult and renders kernel pointer leaks significantly less useful.

However, some regions of the kernel are not randomized (such as symbols before __startup_secondary_64 on x86_64) and offsets remain consistent across reboots. Additionally, FG-KASLR randomizes only kernel functions, leaving other useful kernel data (such as modprobe_path and core_pattern usermode helpers) unchanged at a static offset.

See also:

• [PATCH v10 00/15] Function Granular KASLR
• CONFIG_FG_KASLR
• FGKASLR - CTF Wiki

Not all architectures support KASLR (CONFIG_RANDOMIZE_BASE) or enable it by default:

See also:

• grsecurity - KASLR: An Exercise in Cargo Cult Security (grsecurity, 2013)
• An Info-Leak Resistant Kernel Randomization for Virtualized Systems | IEEE Journals & Magazine | IEEE Xplore (Fernando Vano-Garcia, Hector Marco-Gisbert, 2020)
• Kernel Address Space Layout Randomization (LWN.net)
  • Kernel address space layout randomization [LWN.net]
  • Randomize kernel base address on boot [LWN.net]
  • arm64: implement support for KASLR [LWN.net]
• Kernel load address randomization · Linux Inside
• KASLR Kconfig options:
  • CONFIG_RANDOMIZE_BASE: Randomize the address of the kernel image (KASLR)
  • CONFIG_RANDOMIZE_BASE_MAX_OFFSET: Maximum kASLR offset
  • CONFIG_RANDOMIZE_MEMORY: Randomize the kernel memory sections
  • CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING: Physical memory mapping padding
  • CONFIG_RELOCATABLE: Build a relocatable kernel

When KASLR is disabled, the kernel loads at a fixed virtual address — the "default text base." This address is determined by the architecture's linker script, Kconfig options, or hardware memory map. When KASLR is enabled, the kernel is placed at default + N × KERNEL_ALIGN, where N is chosen randomly within the architecture's valid range. KERNEL_ALIGN is therefore the randomization granularity: each possible position is one "KASLR slot."

The "Derivation" column shows where each default address comes from. On most architectures the formula is PAGE_OFFSET + TEXT_OFFSET, where PAGE_OFFSET is the start of the kernel virtual address space (set by hardware mapping or Kconfig) and TEXT_OFFSET is the offset from the mapping base to the .text section entry point (set by the linker script or boot protocol). x86_64 is an exception: the kernel image virtual base (__START_KERNEL_map = 0xffffffff80000000) is separate from PAGE_OFFSET (the direct-map base), and PHYSICAL_START (16 MiB) is added for alignment with the physical load address.

Linux KASLR randomizes the kernel location in both physical memory (where the kernel image resides in RAM) and virtual memory (where the kernel is mapped in the address space). Depending on the architecture, these may be randomized together using a single offset (coupled) or independently using separate offsets (decoupled).

On architectures where physical and virtual randomization are coupled (i.e. the same offset), leaking either a physical or virtual kernel address trivially reveals the other. On architectures where they are decoupled, a physical address leak does not directly reveal the virtual address (and vice versa), providing stronger isolation.

See also:

• security things in Linux v4.8 (Kees Cook, 2016) — describes x86_64 physical/virtual decoupling and CONFIG_RANDOMIZE_MEMORY
• x86, boot: KASLR memory randomization [LWN.net] (Thomas Garnier, 2016) — CONFIG_RANDOMIZE_MEMORY patch series
• Kernel load address randomization · Linux Inside — detailed walkthrough of choose_random_location() on x86

The kernel virtual address space contains distinct sections (text, modules, direct map, etc.) mapped at different address ranges. KASLR randomizes the kernel text base address, but not all sections are randomized together — depending on the architecture, other sections may be at fixed addresses, use the same KASLR offset, or be randomized independently.

On coupled architectures, all sections are at fixed offsets from each other: a physical address reveals the virtual text base via phys_to_virt(), the direct map is at a known offset (TEXT_OFFSET) from the text base, and modules are either at a fixed address or a constant offset from PAGE_OFFSET. A single leak from any section is sufficient to derive the others. On decoupled architectures like x86_64, each section is randomized independently — a physical address tells you nothing about the virtual text base, and the direct map base (page_offset_base) is randomized separately.

RISC-V64 is notable: the module region is anchored to the kernel image (MODULES_VADDR = PFN_ALIGN(&_end) - SZ_2G, MODULES_END = PFN_ALIGN(&_start)), so modules shift with the randomized kernel rather than occupying a fixed region. See Orchestrator derivation rules for how KASLD exploits this.

On 32-bit systems, the 4 GiB virtual address space is divided between userspace and the kernel. The boundary — PAGE_OFFSET (also known as the "vmsplit") — determines where the kernel virtual address space begins.

The most common configuration is a 3G/1G split (PAGE_OFFSET=0xC0000000), but embedded systems and custom kernels may use different splits:

The vmsplit affects nearly all kernel virtual address boundaries: the kernel text base, direct map, and (on some architectures) the module region all shift with PAGE_OFFSET. This means KASLR analysis, address validation, and memory layout interpretation depend on knowing the correct vmsplit.

Since KASLD is typically compiled on one system and deployed to another, the compile-time PAGE_OFFSET assumption may not match the target system. KASLD handles this at runtime: components that detect the actual PAGE_OFFSET (e.g. mmap-brute-vmsplit, boot-config) emit a pageoffset tagged result, and the orchestrator automatically adjusts all layout boundaries before performing validation and analysis.

See also:

• 0xAX/linux-insides
  • https://github.com/0xAX/linux-insides/tree/master/Initialization
  • https://github.com/0xAX/linux-insides/blob/master/Theory/linux-theory-1.md
  • https://github.com/0xAX/linux-insides/tree/master/MM
• Virtual Memory and Linux (Matt Porter, 2016)
• Understanding the Linux Virtual Memory Manager (Mel Gorman, 2004)
• Linux Kernel Programming (Kaiwan N Billimoria, 2021)

KASLR bypass techniques broadly fall into several categories: reading kernel pointers or memory layout details from filesystem interfaces, exploiting microarchitectural or software side-channels, leaking addresses through syscalls and kernel interfaces, brute-forcing memory layout constraints, taking advantage of weak randomization entropy, leveraging patched kernel info leak bugs, and using arbitrary read primitives.

The kernel exposes a variety of information through pseudo-filesystems (/proc, /sys), log files (/var/log), and boot configuration files (/boot, /proc/config.gz) that can reveal kernel pointers or memory layout details to unprivileged users.

Kernel and system logs (dmesg / syslog) offer a wealth of information, including kernel pointers and the layout of virtual and physical memory.

Many KASLD components search the kernel message ring buffer for kernel addresses. The following KASLD components read from dmesg and /var/log/dmesg:

• dmesg_android_ion_snapshot.c
• dmesg_backtrace.c
• dmesg_check_for_initrd.c
• dmesg_cma_reserved.c
• dmesg_crashkernel.c
• dmesg_driver_component_ops.c
• dmesg_e820_memory_map.c
• dmesg_early_init_dt_add_memory_arch.c
• dmesg_efi_memmap.c
• dmesg_ex_handler_msr.c
• dmesg_fake_numa_init.c
• dmesg_free_area_init_node.c
• dmesg_free_reserved_area.c
• dmesg_kaslr-disabled.c
• dmesg_last_pfn.c
• dmesg_mem_init_kernel_layout.c
• dmesg_mmu_idmap.c
• dmesg_node_data.c
• dmesg_ramdisk.c
• dmesg_reserved_mem.c
• dmesg_reserved_mem_opensbi.c
• dmesg_riscv_relocation.c
• dmesg_swiotlb.c

Historically, raw kernel pointers were frequently printed to the system log without using the %pK printk format.

• https://github.com/torvalds/linux/search?p=1&q=%25pK&type=Commits

Bugs which trigger a kernel oops can be used to leak kernel pointers by reading the associated backtrace from system logs (on systems with kernel.panic_on_oops = 0).

For testing purposes, a backtrace can be forced using SysRq (requires root):

echo l > /proc/sysrq-trigger

This prints a backtrace of all CPUs to the kernel log, which the dmesg_backtrace component will then parse. The SysRq l command requires kernel.sysrq to include bit 4 (dump-backtrace), which is enabled by default on most distro kernels (kernel.sysrq = 1 enables all commands).

Most modern distros ship with kernel.dmesg_restrict enabled by default to prevent unprivileged users from accessing the kernel debug log. Similarly, grsecurity hardened kernels support kernel.grsecurity.dmesg to prevent unprivileged access.

System log files (ie, /var/log/syslog) are readable only by privileged users on modern distros. On Debian/Ubuntu systems, users in the adm group also have read permissions on various system log files in /var/log/:

$ ls -la /var/log/syslog /var/log/kern.log /var/log/dmesg
-rw-r----- 1 root   adm 147726 Jan  8 01:43 /var/log/dmesg
-rw-r----- 1 syslog adm    230 Jan 15 00:00 /var/log/kern.log
-rw-r----- 1 syslog adm   8322 Jan 15 04:26 /var/log/syslog

Typically the first user created during installation of an Ubuntu system is a member of the adm group and will have read access to these files.

Additionally, an initscript bug present from 2017-2019 caused the /var/log/dmesg log file to be generated with world-readable permissions (644) and may still be world-readable on some systems.

Various areas of DebugFS (/sys/kernel/debug/*) may disclose kernel pointers.

DebugFS is no longer readable by unprivileged users by default since kernel version v3.7-rc1~174^2~57 on 2012-08-27.

This change pre-dates Linux KASLR by 2 years. However, DebugFS may still be readable in some non-default configurations.

The /proc and /sys pseudo-filesystems expose kernel addresses, memory layout details, symbol information, and hardware configuration. Many of these files are readable by unprivileged users by default.

The following KASLD components read from /proc:

• proc-kallsyms.c — kernel symbol addresses from /proc/kallsyms
• proc-modules.c — loaded module addresses from /proc/modules
• proc-zoneinfo.c — memory zone boundaries from /proc/zoneinfo
• proc-cpuinfo.c — CPU information from /proc/cpuinfo
• proc-pid-syscall.c — kernel stack pointer from /proc/<pid>/syscall
• proc-stat-wchan.c — wait channel address from /proc/<pid>/stat
• proc-cmdline.c — kernel command line from /proc/cmdline (checks for nokaslr)
• proc-config.c — kernel configuration from /proc/config.gz

The following KASLD components read from /sys:

• sysfs_firmware_memmap.c — firmware memory map from /sys/firmware/memmap/
• sysfs_memory_blocks.c — memory block addresses from /sys/devices/system/memory/
• sysfs_pci_resource.c — PCI BAR addresses from /sys/bus/pci/devices/
• sysfs_vmcoreinfo.c — kernel addresses from /sys/kernel/vmcoreinfo
• sysfs_devicetree_initrd.c — initrd address from /sys/firmware/devicetree/
• sysfs_devicetree_memory.c — memory regions from /sys/firmware/devicetree/
• sysfs_iscsi_transport_handle.c — iSCSI transport handle from /sys/class/iscsi_transport/
• sysfs-kernel-notes-xen.c — Xen notes from /sys/kernel/notes
• sysfs-module-sections.c — module section addresses from /sys/module/*/sections/
• sysfs_nf_conntrack.c — netfilter conntrack hash from /sys/module/nf_conntrack/

Most of these are mitigated by kernel.kptr_restrict (for /proc/kallsyms, /proc/modules, etc.) and root-only permissions on sensitive sysfs entries.

Boot configuration and kernel config files can reveal whether KASLR is enabled, the PAGE_OFFSET (vmsplit), and other layout-relevant settings.

The following KASLD components read boot configuration:

• boot-config.c — reads /boot/config-* for CONFIG_RELOCATABLE, CONFIG_RANDOMIZE_BASE, and CONFIG_PAGE_OFFSET
• proc-config.c — reads /proc/config.gz for the same configuration options
• proc-cmdline.c — reads /proc/cmdline to check for nokaslr

There are a plethora of viable side-channel attacks which can be used to break KASLR, including microarchitectural timing attacks, transient execution attacks, and software side-channels that exploit timing variations in kernel algorithms and data structures.

The following table catalogues known side-channel KASLR attacks.

Note: Several related attacks (LVI, RAMBleed) are omitted from the table because they are not KASLR bypass techniques. LVI targets SGX enclaves; RAMBleed is a general memory read primitive (rowhammer-based, hours-slow).

The extra/check-hardware-vulnerabilities script performs rudimentary checks for several known hardware vulnerabilities, but does not implement these techniques.

See also:

• google/safeside — project to understand and mitigate software-observable side-channels (Google)
• Hardening the Kernel Against Unprivileged Attacks (Claudio Canella, 2022)
• Exploiting Microarchitectural Optimizations from Software (Moritz Lipp. 2021)
• transient.fail — overview of speculative / transient execution attacks (Graz University of Technology, 2020)
• LVI: Hijacking Transient Execution through Microarchitectural Load Value Injection (Jo Van Bulck, Daniel Moghimi, Michael Schwarz, Moritz Lipp, Marina Minkin, Daniel Genkin, Yuval Yarom, Berk Sunar, Daniel Gruss, and Frank Piessens, 2020)
• A Systematic Evaluation of Transient Execution Attacks and Defenses (Claudio Canella, Jo Van Bulck, Michael Schwarz, Moritz Lipp, Benjamin von Berg, Philipp Ortner, Frank Piessens, Dmitry Evtyushkin, Daniel Gruss, 2019)
• RAMBleed: Reading Bits in Memory Without Accessing Them (Andrew Kwong, Daniel Genkin, Daniel Gruss, Yuval Yarom, 2019) — google/rowhammer-test
• Micro architecture attacks on KASLR (Anders Fogh, 2016)

Kernel syscalls and device interfaces can leak kernel addresses through return values, uninitialized memory in structures, or sampling kernel events.

The following KASLD components exploit syscall and interface leaks:

• perf_event_open.c — samples kernel event addresses via perf_event_open() (requires kernel.perf_event_paranoid < 2)
• mincore.c — mincore() heap page disclosure via uninitialized memory (CVE-2017-16994; patched in v4.15)
• bcm_msg_head_struct.c — CAN BCM bcm_msg_head struct uninitialized 4-byte hole leaks kernel stack pointer (CVE-2021-34693)
• pppd_kallsyms.c — exploits set-uid pppd to read /proc/kallsyms bypassing kptr_restrict open-time check
• qemu-tcg-iret.c — leaks kernel stack address inside QEMU TCG guests via iret instruction (patched in QEMU 9.1)

Some memory layout properties can be determined by probing the address space directly, without reading any files or exploiting vulnerabilities.

The following KASLD components use brute-force probing:

• mmap-brute-vmsplit.c — determines PAGE_OFFSET (vmsplit) on 32-bit systems by mapping pages across the address space until failure

The kernel is loaded at an aligned memory address, usually between PAGE_SIZE (4 KiB) and 2 MiB on modern systems (see KERNEL_ALIGN definitions in kasld.h). This limits the number of possible kernel locations. For example, on x86_64 with RANDOMIZE_BASE_MAX_OFFSET of 1 GiB and 2 MiB alignment, this limits the kernel load address to 0x4000_0000 / 0x20_0000 = 512 possible locations.

Weaknesses in randomisation can decrease entropy, further limiting the possible kernel locations in memory and making the kernel easier to locate.

KASLR may be disabled if insufficient randomness is generated during boot (for example, if get_kaslr_seed() fails on ARM64).

The following KASLD component provides a baseline reference:

• default.c — reports the hardcoded default kernel text base address for the target architecture, used as the baseline for KASLR slide calculation

See also:

• Another look at two Linux KASLR patches (Kryptos Logic, 2020)
• arm64: efi: kaslr: Fix occasional random alloc (and boot) failure
• Defeating KASLR by Doing Nothing at All (Seth Jenkins, 2025) - arm64 linear map is not randomized due to memory hotplug support; Pixel bootloader loads kernel at static physical address, making kernel virtual addresses fully predictable even with KASLR enabled.

There have been many kernel bugs which leaked kernel addresses to unprivileged users via uninitialized memory, missing pointer sanitization, using kernel pointers as a basis for "random" strings in userland, and many other weird and wonderful flaws. These bugs are regularly discovered and patched.

Patched kernel info leak bugs:

• https://github.com/torvalds/linux/search?p=1&type=Commits&q=kernel-infoleak
• git clone https://github.com/torvalds/linux && cd linux && git log | grep 'kernel-infoleak'

Patched kernel info leak bugs caught by KernelMemorySanitizer (KMSAN):

• https://github.com/torvalds/linux/search?p=1&type=Commits&q=BUG: KMSAN: kernel-infoleak
• git clone https://github.com/torvalds/linux && cd linux && git log | grep "BUG: KMSAN: kernel-infoleak"

Netfilter info leak (CVE-2022-1972):

• Yet another bug into Netfilter
  • https://github.com/randorisec/CVE-2022-1972-infoleak-PoC

Remote uninitialized stack variables leaked via Bluetooth:

• BadChoice: Stack-Based Information Leak (BleedingTooth) (CVE-2020-12352)
• Linux Kernel: Infoleak in Bluetooth L2CAP Handling (CVE-2022-42895)
• Info Leak in the Linux Kernel via Bluetooth (CVE-2017-1000410)

Remote kernel pointer leak via IP packet headers (CVE-2019-10639):

• From IP ID to Device ID and KASLR Bypass

floppy block driver show_floppy kernel function pointer leak (CVE-2018-7273) (requires floppy driver and access to dmesg).

• Linux Kernel < 4.15.4 - 'show_floppy' KASLR Address Leak (Gregory Draperi. 2018)
• https://xorl.wordpress.com/2018/03/18/cve-2018-7273-linux-kernel-floppy-information-leak/

kernel_waitid leak (CVE-2017-14954) (affects kernels 4.13-rc1 to 4.13.4):

• wait_for_kaslr_to_be_effective.c (spender, 2017)
• https://github.com/salls/kernel-exploits/blob/master/CVE-2017-5123/exploit_no_smap.c (salls, 2017)

snd_timer_user_read uninitialized kernel heap memory disclosure (CVE-2017-1000380):

• Linux kernel 2.6.0 to 4.12-rc4 infoleak due to a data race in ALSA timer (Alexander Potapenko, 2017)
  • snd_timer_c.bin (Alexander Potapenko, 2017)

Uninitialized kernel heap memory in ELF core dumps (CVE-2020-10732). fill_thread_core_info() in fs/binfmt_elf.c allocated regset data buffers with kmalloc(), which were not fully initialized by regset get() callbacks. Several kilobytes of stale kernel heap data (potentially containing kernel pointers) could be written to the core file and read by an unprivileged user. Trivially exploitable by crashing any program:

• google/kmsan#76: Uninitialized memory in ELF core dump
• Bug 1831399 - CVE-2020-10732 kernel: uninitialized kernel data leak in userspace coredumps
• fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() (Alexander Potapenko, 2020)

Uninitialized x86 FPU/xstate data in core dumps. copy_xstate_to_kernel() only copied enabled xstate features, leaving gaps between features uninitialized. Stale kernel memory was leaked through the NT_X86_XSTATE ELF core dump note:

• copy_xstate_to_kernel(): don't leave parts of destination uninitialized (Al Viro, 2020)

RISC-V kernel gp register leaked to userland (CVE-2024-35871) (affects kernels 4.15 to 6.8.5). The kernel __global_pointer$ was exposed via childregs->gp in user_mode_helper threads (PID 1, core_pattern pipe handlers, etc), observable through kernel_execve register state, ptrace(PTRACE_GETREGSET), and PERF_SAMPLE_REGS_USER:

• riscv: process: Fix kernel gp leakage

PPTP sockets pptp_bind() / pptp_connect() kernel stack leak (CVE-2015-8569):

• https://lkml.org/lkml/2015/12/14/252

Exploiting uninitialized stack variables:

• Structure holes and information leaks (Jonathan Corbet. 2010)
• C Structure Padding Initialization (Noah Pendleton. 2022)
• DCL39-C. Avoid information leakage when passing a structure across a trust boundary - SEI CERT C Coding Standard
• Exploiting Uses of Uninitialized Stack Variables in Linux Kernels to Leak Kernel Pointers (Haehyun Cho, Jinbum Park, Joonwon Kang, Tiffany Bao, Ruoyu Wang, Yan Shoshitaishvili, Adam Doupé, Gail-Joon Ahn. 2020)
  • Leak kernel pointer by exploiting uninitialized uses in Linux kernel
  • jinb-park/leak-kptr
  • compat_get_timex kernel stack pointer leak (CVE-2018-11508).
  • sctp_af_inet kernel pointer leak (CVE-2017-7558) (requires libsctp-dev).
  • rtnl_fill_link_ifmap kernel stack pointer leak (CVE-2016-4486).
  • snd_timer_user_params kernel stack pointer leak (CVE-2016-4569).

Kernel vulnerabilities which provide arbitrary read (or write) primitives can be leveraged to leak kernel pointers and defeat KASLR, even when direct info leak vectors are unavailable.

Leaking kernel addresses using msg_msg struct for arbitrary read (for KMALLOC_CGROUP objects):

• Four Bytes of Power: Exploiting CVE-2021-26708 in the Linux kernel | Alexander Popov
• CVE-2021-22555: Turning \x00\x00 into 10000$ | security-research
• Exploiting CVE-2021-43267 - Haxxin
• Will's Root: pbctf 2021 Nightclub Writeup: More Fun with Linux Kernel Heap Notes!
• Will's Root: corCTF 2021 Fire of Salvation Writeup: Utilizing msg_msg Objects for Arbitrary Read and Arbitrary Write in the Linux Kernel
• [corCTF 2021] Wall Of Perdition: Utilizing msg_msg Objects For Arbitrary Read And Arbitrary Write In The Linux Kernel
• [CVE-2021-42008] Exploiting A 16-Year-Old Vulnerability In The Linux 6pack Driver

Leaking kernel addresses using privileged arbitrary read (or write) in kernel space:

• kptr_restrict – Finding kernel symbols for shell code (ryiron, 2013)
• CVE-2017-18344: Exploiting an arbitrary-read vulnerability in the Linux kernel timer subsystem (xairy, 2017):
  • https://www.openwall.com/lists/oss-security/2018/08/09/6
  • https://xairy.io/articles/cve-2017-18344
  • xairy/kernel-exploits/CVE-2017-18344

KASLD is MIT licensed but borrows heavily from modified third-party code snippets and proof of concept code.

Various code snippets were taken from third-parties and may have different license restrictions. Refer to the reference URLs in the comment headers available in each file for credits and more information.