Address Sanitizer (ASan) — detecting buffer overflows at runtime

5.3.12 · Coding › Build Systems & Toolchain

WHAT hai ASan?

Yeh static analysis nahi hai (yeh compile time pe tumhara code reason nahi karta) aur Valgrind ki tarah ek alag VM bhi nahi hai. Balki compiler tumhare loads aur stores ke aas-paas extra check code inject karta hai, aur ek runtime library malloc/free ko replace karti hai.

WHY chahiye humein yeh? (the problem)

C/C++ tumhe raw pointers deta hai bina kisi bounds checking ke. Yeh fast hai lekin dangerous hai:

int a[4];
a[4] = 42;   // writes 1 element past the end — undefined behaviour

Plain execution often kaam karta dikh-ta hai (tum bas kuch adjacent memory smash kar dete ho), phir 10,000 lines baad mysteriously crash ho jaata hai. Aise bugs ~70% security CVEs ka karan hain. Humein kuch chahiye jo loudly, immediately, exact line pe fail kare.

HOW kaam karta hai — mechanism ko first principles se derive karo

ASan ke do cooperating pieces hain: shadow memory aur redzones.

1. Shadow memory (the green/red map)

Humein ek quick tarika chahiye yeh poochne ka ki "kya address A valid hai?". Har application byte ke liye ek byte of metadata store karna memory double kar deta. Isliye ASan ek key observation use karta hai:

Application memory 8-byte granules mein aligned hoti hai. Ek granule ke andar, pehle k bytes usually valid hote hain aur baaki poisoned.

To ek shadow byte 8 application bytes describe karta hai. Mapping ek simple affine function hai:

Shadow byte value $s$ encode karta hai ki 8 bytes mein se kitne bytes addressable hain:

s = ⎩ ⎨ ⎧ 0 k, 1 \leq k \leq 7 negative saare 8 bytes valid (green) pehle k bytes valid, baaki poisoned saare 8 poisoned (redzone, freed, etc.)

2. Injected check

Address $A$ par N-byte access ke liye (assume aligned, $N \leq 8$ ), compiler *A = x ko roughly is mein badal deta hai:

shadow = *(char*)(((uintptr_t)A >> 3) + Offset);   // load 1 shadow byte
if (shadow != 0 && ((A & 7) + N - 1) >= shadow)    // last byte index ≥ allowed?
    __asan_report_error(A);                        // poisoned → report & abort
*A = x;                                            // else proceed

3. Buffers ke aas-paas Redzones

ASan ki runtime malloc(n) ko actually $n$ + dono taraf redzones allocate karati hai, aur un redzone shadow bytes ko poison karti hai. Yahi stack arrays (compiler-inserted) aur globals ke liye bhi hota hai. To a[4] ek red strip mein land karta hai aur check fire ho jaata hai.

Figure — Address Sanitizer (ASan) — detecting buffer overflows at runtime

Worked examples

Worked example

Example 1 — Heap overflow.

char *p = malloc(8);   // 8 bytes → exactly one granule, shadow = 0
p[8] = 'x';            // touching the redzone after p

Yeh fire kyun karta hai? p[8] us redzone mein hai jiska shadow byte negative hai (poisoned). Check dekhta hai shadow != 0 → __asan_report_error. ASan print karta hai heap-buffer-overflow ... WRITE of size 1, allocation stack, aur access stack.

Worked example

Example 2 — Partial granule (the subtle one).

char *p = malloc(5);   // 5 bytes used; granule shadow = 5
p[4] = 'a';            // offset 4, 4 < 5  → OK
p[5] = 'b';            // offset 5

Step: compute karo (A&7)+N-1 = 5+1-1 = 5. Compare karo 5 >= shadow(=5) → true → reported. Yeh step kyun? Shadow value 5 matlab "bytes 0–4 valid"; index 5 same granule ke andar pehla poisoned byte hai. Yahi exactly woh case hai jo ek shadow byte per 8 express kar sakta hai.

Worked example

Example 3 — Use-after-free.

char *p = malloc(16);
free(p);
p[0] = 1;             // heap-use-after-free

Kyun? free par, ASan freed region ki shadow ko poison karta hai aur block ko ek quarantine mein daalta hai (use immediately reuse nahi karta). To p[0] ka shadow poisoned hai → reported, aur ASan yeh bhi dikhata hai ki ise kahan free kiya gaya tha.

Common mistakes

Connections

Valgrind Memcheck — slower, no recompile, shadow-by-emulation instead of instrumentation
Undefined Behaviour in C and C++ — woh root cause jo ASan expose karta hai
MemorySanitizer (MSan) aur UndefinedBehaviorSanitizer (UBSan) — sibling sanitizers
Stack vs Heap Memory Layout — kyun redzones region ke hisaab se different hote hain
Compiler Instrumentation and -fsanitize flags
Fuzzing (libFuzzer / AFL) — ASan ke saath pair karo taaki buggy paths tak pahuncho

Recall Feynman: ek 12-saal ke bacche ko explain karo

Socho tumhare khilone ek box ke andar rehne chahiye. ASan har box ke aas-paas "do-not-touch" floor ki ek patli red border paint karta hai. Yeh ek choti si cheat-sheet bhi rakhta hai (8 floor tiles per ek note) jo batati hai ki kaunsi tiles safe hain. Jab bhi tumhara robot hand floor pe reach karta hai, woh pehle cheat-sheet dekhta hai. Green floor pe kadam rakho → theek hai. Red border pe kadam rakho → robot STOP chillata hai aur tumhe exactly batata hai ki tum kis toy box ke paas se nikal gaye. Isi tarah yeh tumhe tumhare box ke bahar pahunchte waqt usi waqt pakad leta hai, baad mein nahi jab sab kuch mess ho chuka ho.

Recall Active recall — quick self-test

Kaunsa formula ek address ko uske shadow byte pe map karta hai?
Ek shadow byte 8 application bytes kyun cover karta hai?
ASan specifically use-after-free kaise detect karta hai?
Ek aise overflow ka naam batao jise ASan miss kar sakta hai.

AddressSanitizer enable karne wala compiler flag kya hai?

-fsanitize=address (GCC aur Clang mein)

ASan mein shadow-address mapping formula kya hai?

Shadow (A) = (A ≫ 3) + Offset

Ek shadow byte 8 application bytes kyun describe karta hai?

Memory ko 8-byte aligned granules mein track kiya jaata hai; shadow byte store karta hai ki un 8 bytes mein se kitne addressable hain (0=saare, k=pehle k, negative=koi nahi).

Shadow value 0 ka matlab kya hai vs negative value?

0 = saare 8 bytes valid (green); negative = poora granule poisoned/redzone (red, illegal).

ASan mein "redzone" kya hota hai?

Poisoned padding jo har buffer (heap, stack, global) ke pehle/baad insert ki jaati hai taaki adjacent overflows poisoned shadow se takraayein aur report hon.

ASan use-after-free kaise pakadta hai?

free() par woh block ki shadow ko poison karta hai aur use quarantine karta hai (reuse delay karta hai), to baad ka access poisoned shadow padhta hai → reported.

A par N-byte access ke liye, report trigger karne wali condition kya hai?

shadow ≠ 0 AND ((A & 7) + N − 1) ≥ shadow, yaani accessed byte poisoned part mein pahunch jaata hai.

Ek aisi OOB bug class batao jo ASan MISS kar sakta hai.

Ek wild pointer jo object se door hai aur kisi doosre valid (green) object ki memory mein land ho jaata hai — beech mein koi redzone nahi.

ASan static hai ya runtime detection?

Runtime — yeh compile time pe loads/stores ko instrument karta hai lekin checks execution ke dauran un paths par run hote hain jo tum actually execute karte ho.

Typical ASan overhead kya hai?

Roughly 2× CPU slowdown aur 2–3× memory use (shadow + redzones + quarantine); yeh ek debug/test tool hai, production ke liye nahi.

ASan ko fuzzing ke saath kyun pair karo?

ASan sirf executed paths par bugs dhundta hai; fuzzing aisi inputs generate karta hai jo zyada paths tak pahunchti hain taaki redzone checks actually fire hon.