Information Security 8 min read

Understanding KASAN: Principles and Usage in the Linux Kernel

KASAN, the Kernel Address Sanitizer, is a built‑in Linux kernel tool that uses shadow memory to mark each 8‑byte block’s accessibility, enabling detection of out‑of‑bounds and use‑after‑free errors while consuming about one‑eighth of RAM and requiring kernel configuration changes to activate.

OPPO Kernel Craftsman
OPPO Kernel Craftsman
OPPO Kernel Craftsman
Understanding KASAN: Principles and Usage in the Linux Kernel

KASAN (Kernel Address Sanitizer) is a dynamic memory‑error detection tool integrated into the Linux kernel. Its main functions are to detect out‑of‑bounds memory accesses and use‑after‑free errors.

How to enable KASAN

To enable KASAN, add the appropriate options to the kernel defconfig (e.g., CONFIG_KASAN=y ). Enabling KASAN consumes 1/8 of the physical RAM for shadow memory, reducing the usable memory. For example, on an 8 GB system the reported MemTotal becomes approximately 6.72 GB:

C:\Users>adb shell "cat /proc/meminfo | grep MemTotal"

MemTotal:       6723572 kB

KASAN principle overview

KASAN creates a shadow memory region where each byte represents the state of 8 bytes of real memory. The shadow byte values are interpreted as follows:

0 – all 8 bytes are accessible.

1‑7 – the first N bytes are accessible, the rest are invalid.

Negative value – the entire 8‑byte block is invalid.

Special magic numbers are written into shadow memory, and on every load/store the corresponding shadow byte is checked to determine whether the operation is valid.

Validity check using shadow memory

The implementation relies on the functions __asan_load##size() and __asan_store##size() . These functions read the shadow byte for the accessed address and apply the following rules:

If an 8‑byte access finds *shadow == 0 , the access is valid; otherwise it is invalid.

For N‑byte accesses (N = 1, 2, 4), the access is valid when *shadow && *shadow > ((unsigned long)addr & 7) + N ; otherwise it is invalid.

Shadow memory handling for buddy‑system allocations

When pages are allocated from the buddy system, the corresponding shadow memory region is filled with 0 (all bytes accessible). When pages are freed, the related shadow region (size = allocated_pages/8) is filled with 0xFF (KASAN_FREE_PAGE), marking the memory as freed.

Steps:

Allocate 4 pages (order = 2) from the buddy list.

Compute the shadow address: shadow_addr = (addr >> 3) + KASAN_SHADOW_OFFSET .

Fill the shadow region with 0.

On free:

Return the 4 pages to the buddy list.

Locate the corresponding shadow region.

Fill the shadow region with 0xFF .

Shadow memory handling for SLUB allocations

When an object is allocated from a SLUB cache (e.g., kmalloc(20) matches kmalloc‑32 ), the shadow bytes for the 32‑byte object become 00 00 04 FC :

00 00 – bytes 0‑15 are fully accessible.

04 – bytes 16‑19 are accessible, the rest of the 8‑byte block are not.

FC – the remaining bytes constitute a redzone (KASAN_KMALLOC_REDZONE) and are inaccessible.

On free, the 4 shadow bytes are overwritten with 0xFB (KASAN_KMALLOC_FREE), and the call‑stack is saved for later reporting.

Other allocation types

Global variables and stack allocations follow similar shadow‑memory filling rules, with implementation details that differ slightly but the overall concept remains the same.

KASAN bug reports

KASAN can generate reports for out‑of‑bounds accesses and use‑after‑free bugs, as illustrated by the example screenshots (omitted here).

Summary

KASAN manages memory‑access legality by maintaining a shadow memory. It effectively detects out‑of‑bounds and use‑after‑free errors, but it cannot detect logical bugs that corrupt the contents of otherwise valid memory.

securityMemory Debuggingkernel developmentLinux kernelKASANShadow Memory
OPPO Kernel Craftsman
Written by

OPPO Kernel Craftsman

Sharing Linux kernel-related cutting-edge technology, technical articles, technical news, and curated tutorials

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.