Why Every Linux Device Driver Developer Must Understand Kernel VAS

When you write a Linux device driver or a kernel module, your code does not run in userland. It runs inside the kernel itself, sharing the same address space as the OS. This means a single bad pointer dereference in your driver can crash the entire system — there is no safety net like there is in user space.

That is why understanding how the kernel has laid out its own virtual address space is not optional. It is the foundation. Every memory allocation API you will ever call from inside the kernel — kmalloc(), vmalloc(), get_free_pages() — maps to a specific region inside the kernel VAS. Before you use them, you need to know what those regions are and why they exist.

In this tutorial — part of our free Linux kernel development course — we walk through every major region of the Linux kernel virtual address space, from the kernel modules region at the top all the way down to the user VAS at the bottom.

The Linux Kernel Virtual Address Space — A Visual Overview

On a 64-bit Linux system (x86_64 or ARM64), the total virtual address space is enormous — 2⁶⁴ bytes in theory. The kernel takes the upper portion of this space for itself. The lower portion is the user virtual address space (VAS). Below is an HTML diagram showing how the kernel VAS is structured from high addresses (top) to low addresses (bottom).

Now let us look at each of these regions in detail. This is the level of understanding you need to become a confident Linux device driver developer.

1. The Kernel Modules (LKMs) Region

When you load a kernel module — a .ko file — using insmod or modprobe, the kernel allocates memory for the module’s code and static data from a special region called the kernel modules region. This is separate from the main kernel image region.

The reason this region exists as a dedicated area is performance. Because it sits close to the main kernel text segment, short jumps and calls (which are faster than far jumps) can be used between the kernel and any loaded module. On x86_64, the kernel modules region is typically just below the main kernel image in address space.

You can print these from inside a kernel module using pr_info() or printk() with the %px format specifier (which prints the actual pointer address, unlike %p which hashes it for security since kernel 4.15).

Printing Kernel Modules Region from an LKM

The following code shows how to print the kernel modules region boundaries from inside a loadable kernel module. You include <linux/module.h> and use the macros directly.

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/pgtable.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("EmbeddedPathashala");
MODULE_DESCRIPTION("Show kernel modules region boundaries");

static int __init vas_demo_init(void)
{
    pr_info("=== Kernel Modules Region ===\n");
    pr_info("MODULES_VADDR : 0x%px\n", (void *)MODULES_VADDR);
    pr_info("MODULES_END   : 0x%px\n", (void *)MODULES_END);
    pr_info("Size          : %lu MB\n",
        (MODULES_END - MODULES_VADDR) / (1024 * 1024));
    return 0;
}

static void __exit vas_demo_exit(void)
{
    pr_info("vas_demo: unloaded\n");
}

module_init(vas_demo_init);
module_exit(vas_demo_exit);

2. The KASAN Shadow Memory Region

KASAN stands for Kernel Address SANitizer. It is a powerful dynamic memory error detection tool built into the Linux kernel. It was ported from the user-space AddressSanitizer (ASAN) tool and adapted for kernel use.

KASAN is available from kernel 4.0 onward for x86_64 and from kernel 4.4 onward for ARM64. It is a compile-time instrumentation technique — the compiler inserts checks around every memory access so that illegal accesses are caught at runtime rather than causing silent corruption or a delayed crash.

What Kind of Bugs Does KASAN Catch?

How KASAN Works — The Shadow Map Concept

KASAN uses a dedicated memory region called the shadow memory region. For every 8 bytes of kernel memory that can be allocated, KASAN keeps 1 byte of shadow state. This means the shadow region is exactly 1/8th the size of the total kernel virtual address space.

Each shadow byte encodes whether the corresponding 8 bytes of real memory are accessible (fully or partially) or poisoned (freed, not yet allocated, out-of-bounds). The compiler-inserted instrumentation checks this shadow byte on every load and store. If the shadow byte says the memory is poisoned, KASAN immediately reports the violation with full context — the guilty address, the type of access, the stack trace, and even the allocation/free history if shadow call stacks are enabled.

3. The vmalloc Region

The vmalloc region is the area of kernel virtual address space from which the vmalloc() family of functions allocates memory. The key characteristic of vmalloc memory is that it is virtually contiguous but physically non-contiguous.

vmalloc vs kmalloc — What Is the Difference?

This is one of the most common questions in any Linux device driver interview or exam. Here is a clear comparison:

Simple vmalloc Usage Example

#include <linux/vmalloc.h>

/* Allocate 2 MB virtually contiguous */
void *buf = vmalloc(2 * 1024 * 1024);
if (!buf) {
    pr_err("vmalloc failed\n");
    return -ENOMEM;
}

/* Use buf ... */

vfree(buf);   /* Always free with vfree(), not kfree() */