Linux Process User Virtual Address Space – mm_struct, Segments & the NULL Trap Page

When a program runs on Linux, the operating system creates a virtual address space for it. This address space is divided into two halves: the kernel segment (which we covered in the previous tutorial) and the user segment. The user segment is what the program itself actually uses — it holds the program’s code, data, heap, stack, and any shared libraries it loads.

Understanding the Linux process virtual address space at this level is not just academic. It directly affects how you write safer kernel modules, how you debug memory corruption bugs, and how you understand the output of tools like strace, pmap, and /proc/<pid>/maps. This is a core topic in any serious free Linux kernel development course.

The User Segment at a Glance

The user segment of the Linux process virtual address space is not a single flat region. It is a collection of individually mapped regions, each with its own start address, end address, and permission flags (read, write, execute). These individual regions are called Virtual Memory Areas (VMAs), and the kernel tracks each one as a vm_area_struct inside the process’s mm_struct.

The diagram above shows the conceptual layout from top to bottom. In reality, ASLR (Address Space Layout Randomization) randomizes the base of the text segment, the mmap region, and the stack each time a program is launched, so the exact addresses differ per run. But the relative ordering of segments remains the same.

Each Region Explained

Text Segment (Code Segment)

The text segment holds the compiled machine code of the program — the actual instructions the CPU executes. It is mapped read-only and execute-only (on architectures and kernels that support execute-only mappings) so that the program cannot accidentally or maliciously overwrite its own code at runtime.

On 64-bit systems with ASLR enabled, the text segment base address is randomized every time the program starts. You can verify this yourself with a simple experiment:

/* show_addr.c – compile and run twice to see ASLR in action */
#include <stdio.h>

void my_function(void) { }

int main(void)
{
    printf("Text (main)       : %p\n", (void *)main);
    printf("Text (my_function): %p\n", (void *)my_function);
    return 0;
}

/* Compile: gcc -o show_addr show_addr.c  */
/* Run twice and compare the addresses    */

Data Segment and BSS

Global and static variables that are initialized with a non-zero value live in the data segment. Variables that are declared but not initialized (or initialized to zero) live in BSS (Block Started by Symbol). BSS is not stored in the ELF binary on disk — the kernel simply maps zero-filled pages when the program loads. This is why large zero-initialized arrays do not inflate binary sizes.

/* Demonstrating data vs BSS in C */

int global_initialized = 42;   /* Lives in DATA segment */
int global_uninitialized;       /* Lives in BSS segment  */
static int static_zero = 0;    /* Lives in BSS segment  */

int main(void)
{
    /* Local variables live on the STACK (not in data or BSS) */
    int local_var = 10;

    /* Heap-allocated memory comes from the HEAP segment */
    int *heap_ptr = malloc(sizeof(int) * 100);

    printf("data: %p\n", (void *)&global_initialized);
    printf("bss : %p\n", (void *)&global_uninitialized);
    printf("heap: %p\n", (void *)heap_ptr);
    printf("stk : %p\n", (void *)&local_var);

    free(heap_ptr);
    return 0;
}

Heap Segment

The heap is where dynamically allocated memory lives — memory requested via malloc(), calloc(), realloc(), or the brk()/sbrk() system calls directly. The heap grows upward in the virtual address space as more memory is allocated.

The kernel tracks two key addresses for the heap in mm_struct: start_brk (the initial top of the heap when the program was loaded) and brk (the current top of the heap). When malloc() calls brk() or mmap() to get more memory from the OS, the kernel updates these values.

mmap Region (Shared Libraries and File Mappings)

The mmap region is where the dynamic linker places shared libraries like libc.so, libpthread.so, and your application’s other dependencies. It is also where anonymous mmap() calls for large allocations land, and where explicitly memory-mapped files appear.

This region typically sits between the heap and the stack. On 64-bit systems with ASLR, the base of the mmap region is randomized at program startup.

# See exactly what is mapped in a live process
# Replace 1234 with any real PID (or use $$ for the shell itself)
cat /proc/$$/maps

Each line in /proc/<pid>/maps corresponds to one VMA. The format is:

start-end  perms  offset  dev  inode  pathname

Example output:
55a3c1234000-55a3c1236000 r--p 00000000 08:01 1234567  /usr/bin/bash
55a3c1236000-55a3c1240000 r-xp 00002000 08:01 1234567  /usr/bin/bash
55a3c1240000-55a3c1244000 r--p 0000c000 08:01 1234567  /usr/bin/bash
55a3c1244000-55a3c1245000 r--p 0000f000 08:01 1234567  /usr/bin/bash
55a3c1245000-55a3c1246000 rw-p 00010000 08:01 1234567  /usr/bin/bash
7f8a2c000000-7f8a2c028000 rw-p 00000000 00:00 0        [heap]
7f8a30000000-7f8a301c0000 r-xp 00000000 08:01 987654   /lib/x86_64-linux-gnu/libc.so.6
7ffd12345000-7ffd12367000 rw-p 00000000 00:00 0        [stack]

Stack Segment

The stack holds local variables, function call frames, return addresses, and function arguments. Unlike the heap, the stack grows downward — from a high address toward lower addresses as function calls are made. When a function returns, the stack shrinks back up.

The kernel sets the initial stack pointer to near the top of the user virtual address space. Just above the stack pointer live the command-line argument strings (argv) and environment variable strings, which the kernel copies there before handing control to the program’s entry point.

The NULL Trap Page — Virtual Page Zero

At the very beginning of the user virtual address space — starting at virtual address 0x00000000 — sits a special page called the NULL trap page. This is virtual page zero, and it has no permissions: it is not readable, not writable, and not executable.

The NULL trap page exists specifically to catch one of the most common programming bugs: the NULL pointer dereference. When a C program writes code like int *p = NULL; *p = 5;, the CPU tries to write to virtual address 0. Because page zero has no permissions set in the page tables, the MMU immediately raises a page fault. The kernel’s page fault handler sees that address zero is not a valid mapping, so it sends SIGSEGV to the process, which terminates.

This is an intentional design choice. If page zero were mapped and writable, a NULL pointer bug might silently corrupt data instead of crashing immediately. The NULL trap page makes these bugs crash-and-burn visible, which is far better for debugging than silent corruption.

# Check the mmap_min_addr on your system
cat /proc/sys/vm/mmap_min_addr
# Typical output: 65536

# This means user space cannot map any address below 64 KB
# The NULL trap page and the pages around it are protected

The mm_struct — Kernel’s View of a Process Memory Map

For every process (and every thread group), the Linux kernel maintains a data structure called mm_struct. This structure is the kernel’s complete description of a process’s Linux process virtual address space. It holds pointers to the list of VMAs, the page tables, and a set of fields that record the boundaries of each named segment.

The mm_struct is defined in include/linux/mm_types.h in the kernel source. Let us look at the fields that describe the user segment boundaries:

Accessing mm_struct from a Kernel Module

From inside a kernel module, you can access the mm_struct of the current process through the current pointer. The current macro always points to the task_struct of the thread currently running on the CPU. The task_struct has a field mm that points to the process’s mm_struct.

/* kernel_mm_inspect.c – inspect current process mm_struct */
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/mm.h>
#include <linux/mm_types.h>

static int __init mm_inspect_init(void)
{
    struct mm_struct *mm;

    /*
     * 'current' is the task_struct of the process/thread
     * that triggered this module's init (usually insmod itself).
     * For a kernel thread, mm is NULL. Always check before use.
     */
    mm = current->mm;

    if (!mm) {
        pr_info("mm_inspect: called from kernel thread — no user mm\n");
        return 0;
    }

    /* Use mmap_read_lock to safely read mm fields */
    mmap_read_lock(mm);

    pr_info("=== mm_struct for PID %d (%s) ===\n",
            current->pid, current->comm);

    pr_info("Text  : 0x%lx – 0x%lx  (%lu KB)\n",
            mm->start_code, mm->end_code,
            (mm->end_code - mm->start_code) / 1024);

    pr_info("Data  : 0x%lx – 0x%lx  (%lu bytes)\n",
            mm->start_data, mm->end_data,
            mm->end_data - mm->start_data);

    pr_info("Heap  : start_brk=0x%lx  current brk=0x%lx\n",
            mm->start_brk, mm->brk);

    pr_info("Stack : start=0x%lx\n", mm->start_stack);

    pr_info("Args  : 0x%lx – 0x%lx  (%lu bytes)\n",
            mm->arg_start, mm->arg_end,
            mm->arg_end - mm->arg_start);

    pr_info("Env   : 0x%lx – 0x%lx  (%lu bytes)\n",
            mm->env_start, mm->env_end,
            mm->env_end - mm->env_start);

    pr_info("Total VMAs  : %d\n", mm->map_count);
    pr_info("Total pages : %lu  (%lu MB)\n",
            mm->total_vm,
            (mm->total_vm * PAGE_SIZE) / (1024 * 1024));

    mmap_read_unlock(mm);
    return 0;
}

static void __exit mm_inspect_exit(void)
{
    pr_info("mm_inspect: unloaded\n");
}

module_init(mm_inspect_init);
module_exit(mm_inspect_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Inspect current process mm_struct");

Walking the VMA List from a Kernel Module

Every distinct memory region in a process is described by a vm_area_struct. The kernel maintains them in a red-black tree for fast lookup by address, and also in a linked list for sequential iteration. From a kernel module, you can iterate over all VMAs of a process using the VMA_ITERATOR macro or the older linked-list approach.

/* Walk all VMAs of the current process */
#include <linux/module.h>
#include <linux/mm.h>
#include <linux/mm_types.h>

static void dump_vmas(struct mm_struct *mm)
{
    struct vm_area_struct *vma;
    unsigned long total_kb = 0;
    int count = 0;

    /* mmap_read_lock must already be held by the caller */
    VMA_ITERATOR(vmi, mm, 0);

    pr_info("%-20s %-20s %-6s  %s\n",
            "Start", "End", "Perms", "Name");
    pr_info("----------------------------------------------------\n");

    for_each_vma(vmi, vma) {
        unsigned long size_kb = (vma->vm_end - vma->vm_start) / 1024;
        char perms[5] = "----";

        if (vma->vm_flags & VM_READ)    perms[0] = 'r';
        if (vma->vm_flags & VM_WRITE)   perms[1] = 'w';
        if (vma->vm_flags & VM_EXEC)    perms[2] = 'x';
        if (vma->vm_flags & VM_SHARED)  perms[3] = 's';
        else                             perms[3] = 'p';

        pr_info("0x%016lx-0x%016lx  %s  %6lu KB  %s\n",
                vma->vm_start, vma->vm_end, perms, size_kb,
                vma->vm_file ? vma->vm_file->f_path.dentry->d_name.name
                             : "[anon]");

        total_kb += size_kb;
        count++;
    }

    pr_info("Total: %d VMAs, %lu KB mapped\n", count, total_kb);
}

static int __init vma_walk_init(void)
{
    struct mm_struct *mm = current->mm;
    if (!mm) return 0;

    mmap_read_lock(mm);
    dump_vmas(mm);
    mmap_read_unlock(mm);
    return 0;
}

static void __exit vma_walk_exit(void) { }

module_init(vma_walk_init);
module_exit(vma_walk_exit);
MODULE_LICENSE("GPL");

How ASLR Works Inside the Kernel

Address Space Layout Randomization (ASLR) is implemented in the kernel’s ELF loader and mmap() implementation. When a new process is created and an ELF binary is loaded, the kernel picks random offsets for:

• The text/data segment base (position-independent executables compiled with -fPIE -pie)
• The mmap base address (where shared libraries and anonymous mappings start)
• The stack start address (randomized by a few megabytes up or down)

The randomization is controlled by /proc/sys/kernel/randomize_va_space:

# Check ASLR setting
cat /proc/sys/kernel/randomize_va_space

# See ASLR in action: run the same binary twice and compare maps
cat /proc/$$/maps | grep "r-xp" | head -3
# Open another shell and repeat — different addresses!

Comparing User VAS: 32-bit vs 64-bit

Practical: Reading a Process VAS from User Space

You do not always need a kernel module to inspect process memory. The /proc filesystem exposes a great deal of this information directly from user space. Here are the most useful files:

# /proc/self refers to the process reading the file (your shell)

# Full VMA list (same as /proc/<pid>/maps)
cat /proc/self/maps

# Detailed VMA list including VM flags and page counts
# (requires kernel >= 3.3 and root for some fields)
sudo cat /proc/self/smaps | head -40

# Compact summary: physical memory usage per VMA
cat /proc/self/smaps_rollup

# Process memory statistics (RSS, VSZ, etc.)
cat /proc/self/status | grep -E "Vm|Threads"

# Efficient binary format of maps (faster than parsing text)
# Used by tools like pmap internally
sudo cat /proc/self/pagemap | xxd | head  # raw binary, not human-readable directly

# pmap: human-friendly view of process address space
pmap -x $$

Common Mistakes and Troubleshooting

• Dereferencing user pointers in kernel code: If a user-space pointer is passed to a kernel module through a system call or ioctl, never dereference it directly. Use copy_from_user() and copy_to_user(). Direct dereference causes a kernel Oops or panic.
• Assuming fixed segment addresses: With ASLR enabled, segment addresses change every run. Never hard-code them. Use /proc/self/maps or appropriate library functions at runtime.
• NULL pointer in kernel code is different from user space: In user space, a NULL pointer dereference hits the NULL trap page and sends SIGSEGV to your process — recoverable at the OS level. In the kernel, a NULL pointer dereference causes a kernel Oops or panic — much more severe.
• Forgetting to check mm != NULL: Kernel threads have current->mm == NULL because they have no user-space address space. Always check before using it.
• Not holding mmap_read_lock: Reading VMAs without holding the lock leads to race conditions that produce incorrect results or kernel crashes in SMP environments.

Best Practices When Working with Process VAS

• Always use get_task_mm() and mmput() when accessing the mm_struct of another task — this properly manages the reference count.
• Use access_ok() before calling copy_from_user() on a pointer from user space to validate it belongs to the user’s address space.
• Use find_vma(mm, addr) to find the VMA containing a given address rather than walking the entire list manually.
• When writing to user space from the kernel, always check the return value of copy_to_user() — a non-zero return means some bytes were not copied because the user pointer became invalid.
• Keep kernel module code out of the hot path if it walks VMAs — the mmap lock is a reader-writer lock but contention still hurts performance.

Summary and Key Takeaways

FAQ: Linux Process User Virtual Address Space

Outbound References

• Linux Kernel Memory Management Documentation – kernel.org
• Linux Memory Management Concepts – kernel.org
• proc(5) man page – /proc/pid/maps format – man7.org