Common memory errors — null dereference, buffer overflow, use-after-free, double free, memory leak: Worked examples

5.1.18 · D3 · Coding › C Programming › Common memory errors — null dereference, buffer overflow, us

Kisi bhi code se pehle, ek picture jo us vocabulary ko fix kare jo hum baar baar use karte hain. Neeche ki figure mein, memory ko numbered lockers ki ek row ki tarah draw kiya gaya hai. Yellow sticky note p ko dekho: isme tumhara data nahi hota, yeh sirf ek locker number ("4") hold karta hai aur ek arrow us locker ki taraf point karta hai. Teen blue-outlined lockers (3, 4, 5) tumhara owned block hain. Dayi taraf pink note dekho — woh same number "4" dikhata hai lekin uska arrow dashed hai: yeh ek dangling pointer hai jab block free ho jaata hai. Conclusion: do notes ek hi locker ko naam de sakte hain, lekin sirf ek ka uspe legal ownership hota hai.

Figure — Common memory errors — null dereference, buffer overflow, use-after-free, double free, memory leak

Figure s01 neeche definition box ki vocabulary illustrate karta hai — jab bhi "owned block" ya "dangling pointer" aaye, isko refer karo.

Definition Har example mein use hone wale words aur units

Pointer — ek sticky note jo ek byte address hold karta hai (ek number jo ek locker ko naam deta hai). Empty note = NULL = address 0.
Owned block — heap lockers ka ek stretch jo malloc ne tumhe diya; tumhe ise ek baar free se wapas karna hai.
Dangling pointer — ek note jo abhi bhi ek locker number dikhata hai jabki woh locker wapas kar diya gaya ho. Number valid lagta hai lekin locker ab tumhara nahi.
UB — short for ==undefined behaviour==: aisa behaviour jis par C standard koi requirement nahi laagata, isliye program crash ho sakta hai, data corrupt ho sakta hai, ya kaam karta hua bhi dikh sakta hai (dekho Undefined Behaviour).
UAF — short for ==use-after-free==: ek pointer ko dereference karna jab uska block free ho chuka ho. Yeh UB ka ek type hai.
GiB — ek gibibyte, ek binary unit jo $2^{30} = 1, 073, 741, 824$ bytes ke barabar hai. GB (gigabyte) se alag hai, jo ek decimal unit hai jo $1 0^{9} = 1, 000, 000, 000$ bytes ke barabar hai. Hum apni saari arithmetic mein GiB use karte hain kyunki memory sizes powers of two hote hain.

Scenario matrix

Neeche har cell ek alag situation hai jisme ek memory bug ho sakta hai. Jo examples aate hain wo un cell(s) ke saath tagged hain jo wo cover karte hain, taaki tum dekh sako ki poora grid fill hua hai.

#	Cell class	Concrete situation	Example
C1	Null path — failure	`malloc` returns `NULL`, pointer dereferenced	Ex. 1
C2	Null path — success + guard	`malloc` succeeds, guarded correctly	Ex. 1
C3	Bounds — string, off-by-one	Buffer `\0` byte ki wajah se chhota	Ex. 2
C4	Bounds — loop index degenerate	Array par `<=` vs `<`	Ex. 3
C5	Zero / degenerate size	`malloc(0)`, empty string, `n = 0`	Ex. 4
C6	Lifetime — use-after-free	Freed pointer se read/write	Ex. 5
C7	Lifetime — double free	`free` do baar call hua	Ex. 6
C8	Leak — reassignment / early return	Last handle kho gaya	Ex. 7
C9	Real-world word problem	Long-running server, bytes count karna	Ex. 8
C10	Exam twist	Safe lagta hai, UB hai — do rules combine	Ex. 9
C11	Combined bug in the null path	`malloc` fail hota hai, phir null use hota hai aur double-free bhi	Ex. 10

Recall Padhne se pehle quick self-test

Kaun si ek akeli line of code C6 aur C7 dono ko neutralise karti hai? ::: p = NULL; immediately free(p) ke baad — kyunki free(NULL) guaranteed no-op hai aur baad mein *p ek detectable null deref ban jaata hai.

Example 1 — C1 & C2: null path, dono branches

Worked example Ek billion ints allocate karo, phir use karo

int *p = malloc(sizeof(int) * 1000000000ULL); // lagbhag 3.7 GiB request
p[0] = 42;

Forecast: abhi andaza lagao — kya yeh hamesha, kabhi nahi, ya kabhi kabhi crash hota hai? Risky line kaun si hai?

Step 1 — Puchho malloc kya promise karta hai. malloc(bytes) us many bytes ke ek fresh block ka address return karta hai, ya NULL agar jagah na mile. Yeh step kyun? Kyunki poora bug isi par hinga karta hai ki in dono mein se kya hua, aur upar ka code ne kabhi pucha hi nahi.

Step 2 — Request ka size nikalao. sizeof(int) ek typical machine par $4$ bytes hota hai. Toh request hai $4 \times 1, 000, 000, 000 = 4, 000, 000, 000 bytes \approx 3.73 GiB .$ Yeh step kyun? Itni badi request aksar fail hoti hai, isliye NULL branch theoretical nahi, realistic hai.

Step 3 — Failure branch trace karo (cell C1). Agar malloc NULL return kare, toh p == 0. Line p[0] = 42; ka matlab hai "address 0 + 0 par 42 likho". Address 0 OS ke through unmapped hai → segfault (null dereference, UB). Yeh step kyun? Hume failure branch ko uske consequence tak follow karna padega — warna hum kabhi nahi dekhte ki crash write se aata hai, allocation se nahi.

Step 4 — Fix (cell C2).

int *p = malloc(sizeof(int) * 1000000000ULL);
if (p == NULL) { fprintf(stderr, "out of memory\n"); return 1; }
p[0] = 42;   // ab guaranteed valid hai

Yeh step kyun? Ek if ek random crash ko ek controlled, reported failure mein badal deta hai.

Verify: bytes requested $= 4 \times 1 0^{9}$ ; GiB mein $4 \times 1 0^{9} / 2^{30} \approx 3.7253$ GiB. Forecast ka jawab: kabhi kabhi (sirf tab crash hota hai jab OS allocation refuse kare), aur risky line p[0] = 42 hai, malloc nahi.

Example 2 — C3: classic string off-by-one

Worked example Ek greeting ko fixed buffer mein copy karo

char buf[8];
strcpy(buf, "hello world");

Forecast: source ko kitne bytes chahiye, aur buf kitna hold karta hai? Hum kitne se overflow karte hain?

Is pure example mein $L$ = string length (copy hone wale text mein visible characters ki tadaad) aur $N$ = buffer size (destination array ke bytes ki tadaad).

Step 1 — Source bytes gino. "hello world" mein $11$ visible characters hain, isliye $L = 11$ . Ek C string hamesha ek invisible null terminator \0 se khatam hoti hai (dekho Strings in C and the null terminator). Isliye bytes mein true length hai $L + 1 = 11 + 1 = 12.$ Yeh step kyun? strcpy jab tak aur jab tak \0 tak copy karta hai; yeh destination ka size kabhi nahi dekhta.

Step 2 — Parent note ki size law apply karo. $N$ bytes ka buffer $L$ chars ki string ko legally hold kar sakta hai sirf agar $L + 1 \leq N$ ho. Yahan $N = 8$ (char buf[8] se), isliye $L + 1 = 12, N = 8, 12 \leq 8 FALSE hai.$ Yeh step kyun? Yahi woh single inequality hai jo har string-overflow question decide karti hai — hum eyeballing ki jagah apne numbers isme plug karte hain.

Step 3 — Overflow measure karo. End ke baad write hue bytes $= (L + 1) - N = 12 - 8 = 4$ . Woh $4$ bytes stack par buf ke baad jo bhi hai use clobber karte hain — shayad ek saved return address (dekho Buffer Overflow Exploits). Yeh step kyun? Exact overflow count jaanna batata hai kitni adjacent memory corrupt hui, jispar ek exploit ya crash actually depend karta hai.

Step 4 — Fix.

snprintf(buf, sizeof buf, "%s", "hello world"); // zyada se zyada 8 bytes likhta hai, hamesha \0-terminated

Yeh step kyun? snprintf ko size batayi jaati hai, isliye woh overflow ki jagah truncate karta hai.

Verify: $L + 1 = 12$ , $N = 8$ , overflow $= 12 - 8 = 4$ bytes. buf[8] mein snprintf se truncated result "hello w" hai (7 chars + \0).

Example 3 — C4: fencepost loop

$n$ = array size (array mein slots ki tadaad — yahan $n = 5$ from int a[5]).

Step 1 — Legal indices list karo. Array a[5] ke valid indices $0, 1, 2, 3, 4$ hain — exactly $n = 5$ slots, top index $n - 1 = 4$ . Yeh step kyun? C 0 se index karta hai, isliye aakhri valid index hamesha size se ek kam hota hai.

Step 2 — Loop asliyat mein kya visit karta hai. i <= 5 run karta hai i = 0,1,2,3,4,5. Aakhri i = 5 write karta hai a[5] — end se ek past. Yeh step kyun? <= boundary include karta hai; < nahi karta.

Step 3 — Damage count karo. Loop $n + 1 = 6$ baar run karta hai lekin sirf $n = 5$ slots legal hain, isliye out-of-bounds writes $= 6 - 5 = 1$ . Array ke baad ek int (4 bytes) stomp hota hai. Yeh step kyun? "Off-by-one" ko explicit count $6 - 5 = 1$ mein turn karna makes it undeniable ki exactly ek write illegal hai.

Step 4 — Fix. <= ko < se badlo: for (int i = 0; i < 5; i++).

Verify: <= wala loop $6$ baar iterate karta hai ( $0$ se $5$ tak), legal slots $= 5$ , isliye out-of-bounds writes $= 1$ . < wala loop exactly $5$ baar iterate karta hai.

Example 4 — C5: zero aur degenerate sizes

Step 1 — Zero ka rule padho. malloc(0) ya NULL ya ek unique non-NULL pointer return kar sakta hai jise tum dereference nahi kar sakte. Dono legal hain. Yeh step kyun? Kaafi overflow bugs is assumption se aate hain ki size positive hai; zero ek real case hai jo handle karna padta hai.

Step 2 — Check karo ki free dono branches mein safe hai.

Agar p == NULL: free(NULL) guaranteed no-op hai → safe.
Agar p != NULL: yeh ek real (zero-usable-byte) block hai → free(p) correct hai.

Toh snippet ek bug nahi hai. Bug hoga p[0] = 'x'; — zero-size block read/write karna UB hai. Yeh step kyun? Kyunki "kya yeh bug hai?" ka jawab sirf dono possible return values check karke diya ja sakta hai — single-branch check aadha case miss kar deta.

Step 3 — Degenerate string case. Empty string "" abhi bhi $L + 1 = 0 + 1 = 1$ byte occupy karta hai (sirf \0), jahan $L = 0$ string length hai. Isliye char e[1]; strcpy(e, ""); legal hai; char e[0] terminator bhi hold nahi kar sakta. Yeh step kyun? Empty string sabse chhota input hai; agar hamaari size law $L + 1 \leq N$ yahan bhi hold karti hai, toh everywhere hold karti hai, isliye hum boundary explicitly test karte hain.

Verify: empty string byte count $= 0 + 1 = 1$ ; "" ke liye minimum buffer $N \geq 1$ . free(NULL) koi operation nahi karta (crash nahi).

Example 5 — C6: use-after-free, aur kyun `free` tumhari madad nahi kar sakta

Upar definition box ki do abbreviations yaad karo: UAF = use-after-free, aur UB = undefined behaviour.

Step 1 — free(p) actually kya change karta hai. free address ki ek copy receive karta hai (pass-by-value). Woh block allocator ki free-list ko return karta hai lekin tumhara variable p touch nahi karta — figure dekho. Neeche Figure s02 mein, blue arrow follow karo: address 0x40 ki sirf ek copy free() mein jaati hai. Ab left par yellow box dekho — tumhara variable p us arrow se kabhi reach nahi hota, isliye call ke baad woh abhi bhi 0x40 hold karta hai (pink label), ab ek aise locker ko point karta hai jo allocator ne wapas le liya (bottom par pink heap block). Picture is pure step ka poora argument hai: free p clear nahi kar sakta kyunki usne kabhi p dekha hi nahi.

Figure s02 upar Step 1 ka visual proof hai: blue "copy" arrow free() mein kabhi yellow p box tak nahi pahuncha, isliye p dangling reh jaata hai.

Yeh step kyun? Yahi poori misconception hai: log sochte hain free p ko "clear" kar deta hai. Yeh nahi ho sakta; usne kabhi p nahi dekha, sirf uski value dekhi.

Step 2 — Read diagnose karo. free ke baad, p dangling hai: woh abhi bhi old locker ko naam deta hai, lekin woh locker already agli malloc ko de diya gaya hoga. *p padhna UAF (use-after-free) hai — yeh 7 print kar sakta hai, garbage print kar sakta hai, ya crash ho sakta hai. Classic kabhi kabhi wala behaviour.

Step 3 — Fix.

free(p);
p = NULL;                 // ab *p ek detectable null deref hai, silent corruption nahi

Verify: free se pehle likhi gayi value 7 hai; uski legal read (free se pehle) 7 hai. free ke baad, *p UB hai, isliye koi deterministic value guaranteed nahi.

Example 6 — C7: double free

Step 1 — Ownership trace karo. Pehle free(p) ke baad, 10-byte block allocator ke paas wapas hai. p abhi bhi uska address hold karta hai (dangling, unchanged).

Step 2 — Doosra free. free(p) same address dobara de deta hai. Allocator ek already-free block ko apni free-list mein link karne ki koshish karta hai → metadata corruption, usually modern libc par abort(). Yeh step kyun? Allocator bookkeeping (size, next-free) block ke saath inline store karta hai; re-freeing uspe scribble karta hai.

Step 3 — Ek-line cure (C6 aur C7 dono ko khatam karta hai).

free(p);
p = NULL;          // doosra "free(p)" ab free(NULL) hai → guaranteed no-op
free(p);           // harmless

Verify: ek live block ke distinct frees ki tadaad yahan $2$ hai; ek allocation ke liye correct count $1$ hai; excess $= 2 - 1 = 1$ → double free. p = NULL ke baath, doosri call NULL par operate karti hai (no-op).

Example 7 — C8: reassignment se leak

Step 1 — Allocations aur frees gino. Allocations $A = 2$ (100 bytes, phir 200). Frees $F = 1$ . Yeh step kyun? Conservation law kehta hai ek correct program $A = F$ se khatam hota hai; yahan $A > F$ .

Step 2 — Lost handle identify karo. Line p = malloc(200) 100-byte block ka single pointer overwrite kar deta hai. Woh block ab unreachable hai → leaked.

Step 3 — Quantify karo. Leaked bytes $= 100$ . Freed bytes $= 200$ . Net difference $A - F = 2 - 1 = 1$ orphaned block.

Step 4 — Fix. Reassign karne se pehle pehla block free karo, ya do variables use karo.

Verify: $A = 2$ , $F = 1$ , leaked bytes $= 100$ , freed bytes $= 200$ , orphaned blocks $= A - F = 1$ .

Example 8 — C9: real-world word problem (ek leaking server)

Step 1 — Bytes leaked per second. $rate = 50 \times 512 = 25, 600 bytes/s .$ Yeh step kyun? Har un-freed request exactly ek 512-byte block add karti hai ( $A$ badhta hai, $F$ flat rehta hai), isliye leak ek steady stream hai jis par hum rate laga sakte hain.

Step 2 — Total budget bytes mein. $4 GiB = 4 \times 2^{30} = 4, 294, 967, 296 bytes .$ Yeh step kyun? Rate bytes/s mein hai, isliye budget same unit (bytes) mein hona chahiye divide karne se pehle — warna units cancel nahi honge. Note karo hum GiB ( $2^{30}$ ) use karte hain, GB ( $1 0^{9}$ ) nahi.

Step 3 — Exhaustion tak time, seconds mein. $t = \frac{budget}{rate} = \frac{4 , 294 , 967 , 296 bytes}{25 , 600 bytes/s} \approx 167, 772 s .$ Yeh step kyun? Ek total amount (bytes) ko per-second rate (bytes/s) se divide karne par seconds bachte hain — bytes cancel ho jaate hain, time milta hai.

Step 4 — Seconds ko hours mein convert karo. Ek ghante mein $3600$ seconds hote hain, isliye $\frac{167 , 772 s}{3600 s/h} \approx 46.6 hours .$ Yeh step kyun? Isliye hi leaks itne khatarnak hote hain: lagbhag do din kuch crash nahi hota, phir raat 3 baje OOM-killer strike karta hai. Valgrind and AddressSanitizer jaise tools ise seconds mein pakad lete hain.

Step 5 — Fix. Har session malloc ko request end par free se match karo (ek block ka ek owner).

Verify: rate $= 25600$ B/s; budget $= 4 \cdot 2^{30}$ B; $t \approx 167772$ s; $t /3600 \approx 46.6$ h.

Example 9 — C10: exam twist (safe lagta hai, UB hai)

Worked example Bug dhundho

char *make_tag(void) {
    char tag[16];
    snprintf(tag, sizeof tag, "id-%d", 7);
    return tag;                    // <-- ?
}

Forecast: buffer sahi size ka hai aur snprintf bounded hai — toh kya yeh safe hai? Agar nahi, toh kaun sa error hai?

Step 1 — Bounds check karo (decoy). "id-7" mein $L = 4$ chars hain, isliye $L + 1 = 5 \leq 16 = N$ (buffer size). Overflow rule satisfy hai. Yahan koi buffer overflow nahi — yahi trap hai. Yeh step kyun? Hume pehle obvious suspect clear karna hoga, taaki real bug uske peeche chhipne ki jagah saamne aaye.

Step 2 — Lifetime check karo. tag stack par rehta hai (dekho Stack vs Heap Memory). Jab make_tag return karta hai, uska stack frame destroy ho jaata hai. tag return karna ek aisi memory ka pointer return karna hai jo ab kisi ki nahi — ek dangling pointer, aur koi bhi use UAF-flavoured UB hai. Yeh step kyun? Yahan do rules apply hote hain (bounds AUR lifetime); exam real bug ko ek sahi-se-handle kiye gaye bug ke peeche chhupata hai.

Step 3 — Fix (heap-allocate karo taaki caller ka ownership ho).

char *make_tag(void) {
    char *tag = malloc(16);
    if (!tag) return NULL;
    snprintf(tag, 16, "id-%d", 7);
    return tag;                 // caller ko free() karna hoga
}

Verify: content length check $L + 1 = 5 \leq 16$ hold karta hai (toh decoy sach mein safe hai); actual defect stack address return karna hai, bounds error nahi.

Example 10 — C11: null path mein do bugs stack

Worked example Combined trap

char *p = malloc(BIG);   // suppose yeh FAIL kare → p == NULL
p[0] = 'x';              // (a)
free(p);                 // (b)
free(p);                 // (c)

Forecast: p == NULL ke saath, lines (a), (b), (c) mein se kaun si bugs hain aur kaun si harmless? Padhne se pehle guess karo.

Step 1 — State establish karo. Maano malloc fail hua, isliye p == NULL (address 0). Agle har line ko us ek fact ke khilaf judge karna hai. Yeh step kyun? Combined bugs sirf tab confusing hote hain jab tak pointer ki actual value pin nahi hoti; jab p == NULL fix ho jaata hai, har line decidable ho jaati hai.

Step 2 — Line (a): null dereference. p[0] = 'x'; address 0 par likhta hai → segfault, ek null dereference (UB). Yeh ek genuine bug hai. Yeh step kyun? Yeh dikhata hai ki null path ka pehla shikaar dereference hai, exactly Example 1 ki tarah.

Step 3 — Line (b): free(NULL) safe hai. Kyunki p == NULL, free(p) hai free(NULL), jo standard guarantee karta hai kuch nahi karta. Harmless. Yeh step kyun? Yeh surprising cell hai: "failure path mein free" bug nahi hai jab pointer null ho.

Step 4 — Line (c): abhi bhi safe, double free nahi. Block kabhi actually allocate hi nahi hua, isliye dobara free karne ke liye kuch hai hi nahi. free(NULL) phir se → no-op. Toh usual double-free danger null path mein evaporate ho jaata hai. Yeh step kyun? Yeh prove karta hai ki double-free ke liye ek real, ek baar freed block chahiye — NULL ko do baar free karna double free nahi hai.

Step 5 — Asli lesson. Yahan sirf line (a) bug hai. Agar malloc ke baad if (!p) return; check kiya hota, teeno lines skip ho jaatein. Example 1 ka ek akela guard combined scenario ko bhi dissolve kar deta hai. Yeh step kyun? Yeh combined case ko usi ek discipline (malloc check karo) se jodta hai jo ise khatam kar deti hai.

Verify: p == NULL ke saath: bug count $= 1$ (sirf line (a)); free(NULL) do baar call hoke $0$ operations karta hai; freed real blocks ki tadaad $= 0$ , isliye double-free count $= 0$ .

Coverage check

Recall Kya matrix ke har cell ko fill kiya?

C1/C2 → Ex.1 · C3 → Ex.2 · C4 → Ex.3 · C5 → Ex.4 · C6 → Ex.5 · C7 → Ex.6 · C8 → Ex.7 · C9 → Ex.8 · C10 → Ex.9 · C11 → Ex.10. ::: Gyaarahon cells cover hue.

Flashcards

char buf[8] mein strcpy(buf,"hello world") kitna overflow size cause karta hai?

Source ko 12 bytes chahiye (11 chars + \0), buffer 8 hold karta hai, isliye yeh end se 4 bytes past likhta hai.

int a[5] par for(i=0;i<=5;i++) kitne out-of-bounds writes karta hai?

Exactly 1 (i==5 wala write jo a[5] par karta hai).

Kya malloc(0) ka result free kar sakte ho?

Haan — ya toh NULL return karta hai (free no-op hai) ya ek valid non-dereferenceable block (free correct hai).

p=malloc(100); p=malloc(200); free(p); mein kitne bytes leak hote hain?

100 bytes — pehle block ka single handle overwrite ho gaya.

Kyun local char tag[16] return karna bug hai jab sahi size ka bhi ho?

tag stack par rehta hai; return hone par frame destroy ho jaata hai, dangling pointer bachta hai → UB.

1000000000ULL jaise literal par ULL suffix kya karta hai?

Number ko unsigned long long (64-bit) force karta hai, taaki size multiplication 32-bit int overflow na kare.

Jab p == NULL ho, kya free(p); free(p); double free hai?

Nahi — free(NULL) guaranteed no-op hai; koi real block free nahi hota, isliye double free nahi.

GiB aur GB mein kya fark hai?

GiB binary hai (

2^{30}

bytes); GB decimal hai (

1 0^{9}

bytes).