Heap Metadata Corruption Explained: When One Byte Starts Rewriting the Rules

Imagine a warehouse where every box has a tiny label saying how big it is and which box comes next. You are allowed to change exactly one character on a label. Sounds harmless.

Now imagine the warehouse manager trusts that label completely.

That is basically what happens when a heap allocator consumes corrupted metadata. One byte can change the allocator’s idea of where memory starts, where a free chunk belongs, or which internal structure should be used next.

This article walks through a synthetic example of that exact idea: a tiny input-validation bug becomes a one-byte out-of-bounds write, that write corrupts heap metadata, allocator behavior turns the corruption into broader memory control, and the final primitive reaches a dynamic-linking structure to execute a command.

What Is This Bug, Anyway?

The root problem is a comparison written in a language such as C as if it behaved like a mathematical chained comparison.

A developer may intend:

0 <= index && index < size

but accidentally writes:

0 <= index < size

In C, those are completely different expressions.

The first comparison produces an integer:

0 <= index

which is either 0 or 1.

Then C compares that result against size:

(0 <= index) < size

For almost any size >= 2, that final comparison succeeds.

That turns a supposedly bounded index into a signed offset.

The dangerous part is that the program allocates a buffer and immediately uses the attacker-controlled index:

char *ptr = malloc(size);
ptr[index] = value;
free(ptr);

A negative index writes before the returned user pointer.

That is the vulnerability.

Why Should You Care?

A one-byte write sounds weak until the byte lands in allocator metadata.

Heap allocators store bookkeeping information around user allocations. Depending on the allocator version and the exact chunk layout, nearby bytes may influence:

• Chunk size fields
• In-use bits
• Forward and backward links
• Tcache metadata
• Small-bin relationships
• Internal loader structures later reached through a forged allocation

The important lesson is simple:

Primitive strength depends on placement, not just width.

A one-byte write in useless memory is boring.

A one-byte write next to a chunk header is a crowbar.

A Synthetic Vulnerable Program

Consider this simplified service:

#include <stdio.h>
#include <stdlib.h>

void handle(void) {
    size_t size;
    int index;
    unsigned char value;

    if (scanf("%zu %d %hhu", &size, &index, &value) != 3)
        exit(1);

    if (size > 0x3e8 || !(0 <= index < size))
        exit(1);

    char *ptr = malloc(size);
    ptr[index] = value;
    free(ptr);
}

The intended validation was clearly:

0 <= index && index < size

The actual expression is not that.

A useful audit rule is:

Whenever you see < or <= repeated in one C expression, check whether the author accidentally assumed Python-style chaining.

The Fixed Version

Write the comparisons explicitly:

if (size > 0x3e8 || index < 0 || (size_t)index >= size)
    exit(1);

Now negative indexes are rejected, and the signed-to-unsigned conversion is deliberate rather than accidental.

The allocator never gets a chance to become your accomplice.

Worked Example: From One Byte to Heap Control

Step 1: Build predictable chunks

The first goal is to make the heap layout stable.

Repeated allocations of carefully selected sizes create neighboring chunks:

+------------------+
| chunk A          |
+------------------+
| chunk B          |
+------------------+
| chunk C          |
+------------------+

The exact offsets matter because our primitive is tiny.

We are not trying to spray the heap. We are trying to arrange a few specific metadata bytes at known relative positions.

Step 2: Abuse the signed index

A negative index lets us write before the user pointer.

Conceptually:

returned pointer
      |
      v
[A A A A A A A A]
^
|
metadata nearby

An index such as:

-1

targets the byte immediately before the user region.

Larger negative offsets can reach adjacent chunk fields.

This is why the vulnerable check matters so much. Once negative offsets are accepted, the primitive is no longer “write one byte into my buffer.” It is “write one byte at a chosen nearby address.”

Step 3: Shape allocator metadata

The exploit then uses several allocations and frees to make selected chunk headers interact.

The allocator is not merely storing our data anymore. It is processing our forged metadata.

At this stage, the useful mental model is:

attacker-controlled byte
        |
        v
chunk metadata
        |
        v
allocator bookkeeping
        |
        v
unexpected pointer
        |
        v
future malloc() result

The key trick is to make the allocator perform pointer transformations for us.

Step 4: Exploit tcache and bin bookkeeping

Modern glibc uses multiple freelist mechanisms, including tcache and small/unsorted bins.

The exploit carefully arranges chunks so that a later allocation can return memory associated with metadata rather than an ordinary user buffer.

This is where many heap exploits feel like black magic until you draw the list.

Think of it as teaching the allocator:

"the next free chunk lives here"

instead of:

"the next free chunk lives where the allocator originally expected"

The challenge is making the metadata satisfy the allocator’s consistency checks while still steering the pointer somewhere useful.

Step 5: Account for safe-linking

Modern glibc does not always store tcache pointers in plain form.

A common model is:

stored = real_pointer ^ (location >> 12);

So if you write:

stored = target;

malloc may decode it into garbage.

The correct operation is conceptually:

stored = target ^ (storage_address >> 12);

This detail matters because an otherwise correct tcache-poisoning idea can simply crash on a modern allocator.

A practical debugging rule:

If a heap exploit works on an old libc and instantly dies on a newer one, check safe-linking before blaming the whole strategy.

Step 6: Turn allocator behavior into an arbitrary allocation

Once the corrupted freelist metadata is accepted, a future malloc() can return a pointer into attacker-selected memory.

At that point the primitive has changed dramatically:

1-byte write
    ↓
metadata corruption
    ↓
forged free-list state
    ↓
controlled malloc address

That controlled allocation is the turning point.

You can now write multi-byte application data through a normal allocation API, because the allocator itself gave you a pointer to the target structure.

The attacker no longer needs a giant direct overwrite.

The allocator does the heavy lifting.

Why Dynamic Linking Becomes Interesting

Suppose you can make an allocation point into a writable dynamic-linking structure.

The dynamic linker stores metadata describing shared libraries, symbols, relocations, and symbol lookup information.

That gives you another powerful idea:

Do not necessarily overwrite a famous function pointer. Corrupt the data that the resolver uses to decide what address a symbol should resolve to.

This is especially useful when a straightforward hook target is unavailable or the environment differs from an older libc.

A typical high-level chain is:

controlled allocation
        ↓
forged linker metadata
        ↓
resolver processes attacker-controlled fields
        ↓
symbol resolves to attacker-chosen function
        ↓
controlled command executes

The exact structure layout is version-dependent, which is why matching the target libc matters.

Deterministic Exploitation

A common mistake is to treat this kind of exploit as a guessing game.

It should not be.

The interesting part of the technique is that the layout, chunk sizes, metadata bytes, and resolver structures are deliberately arranged so the same input sequence reaches the same state every time.

That means the exploit can be built as a scripted sequence:

groom
→ corrupt
→ free
→ reallocate
→ obtain controlled chunk
→ write linker metadata
→ trigger resolution
→ execute command

The byte budget can also become part of the exploit design. Every allocation consumes some of the available memory budget, so the cleanest exploit is not necessarily the shortest source code. It is the sequence that produces exactly the necessary heap states without wasting allocations.

Vulnerable Code vs Patched Code

Vulnerable

if (size > MAX || !(0 <= index < size))
    return;

char *p = malloc(size);
p[index] = value;
free(p);

The expression is parsed as:

(0 <= index) < size

The bounds check is broken.

Patched

if (size > MAX || index < 0 || (size_t)index >= size)
    return;

char *p = malloc(size);
p[index] = value;
free(p);

Now the program rejects negative offsets and performs an explicit unsigned comparison against the allocation size.

Audit Points

When reviewing code like this, look for:

1. Repeated relational operators inside one C expression.
2. Signed indexes used against allocation lengths.
3. malloc() immediately followed by ptr[index].
4. free() immediately after attacker-controlled memory access.
5. Small write primitives near chunk metadata.
6. Custom allocators or wrappers that expose free-list manipulation.
7. Assumptions that tcache pointers are stored as raw addresses.
8. Dynamic-linker corruption paths when a controlled allocation primitive exists.

A static grep is surprisingly useful:

grep -RInE '\b0\s*<=|<=\s*[^&|]+<' .

That is not a complete detector, but it is a good way to find suspicious comparisons for manual review.

Common Myths

“One byte is too small to exploit”

Usually false.

A one-byte corruption can alter size flags, pointer bytes, list relationships, or allocator state.

“Safe-linking prevents heap exploitation”

No.

It raises the bar and changes the required primitive. It does not make corrupted allocator metadata harmless.

“You always need a libc leak”

No.

Some modern heap attacks turn allocator metadata and deterministic layout into a useful primitive without first printing a libc address.

“Partial corruption is unreliable”

Not necessarily.

Partial overwrites can be more useful than full ones because they preserve most of a valid pointer while modifying the byte that matters.

Defense: How to Fix It

1. Write C bounds checks explicitly.

   Use:

   index < 0 || (size_t)index >= size

   instead of chained comparisons.

2. Prefer unsigned indexes where negative values have no meaning.

3. Separate input validation from memory access.

4. Turn on compiler hardening and sanitizers during testing.

   Useful options include:

   -Wall -Wextra -Wconversion -fsanitize=address,undefined

5. Test boundary values explicitly:

   -1
   0
   size-1
   size
   size+1

6. Keep allocator assumptions documented and version-specific.

7. Treat crashes during heap operations as security bugs until proven otherwise.

Final Thoughts

Heap exploitation is rarely about one magical instruction.

It is about finding a tiny mistake, placing it next to something important, and persuading a trusted subsystem to amplify it.

The vulnerable program gives the attacker one byte.

The allocator provides the leverage.

The dynamic linker provides the final stage.

And suddenly that “harmless” comparison is doing considerably more work than the author intended.

The safest heap corruption is the one you never let become valid metadata.

References

• glibc malloc internals: https://sourceware.org/glibc/wiki/MallocInternals
• glibc source tree: https://sourceware.org/git/?p=glibc.git