Buffer Overflow

Updated 13 Sep 2026

• •

  What it is

  • •

    A write beyond a buffer's allocated bounds that corrupts adjacent memory, such as a local variable, pointer, or saved return address.

  • •

    On the stack, an overflow may reach other locals, the saved frame pointer, or the saved return address; the actual layout determines the target.

• •

  How it works

  • •

    Determine the buffer's start address and its offset to the target you want to corrupt (another variable, or the saved return address) — either from a disassembly (see Stack Frame Layout) or from a program that discloses its own stack layout directly.

  • •

    Send padding bytes to fill the buffer and everything between it and the target, then the corrupting value itself.

  • •

    High addresses
    [ return addr  ] ← target (control-flow hijack) or
    [ saved rbp    ]
    [ other locals ] ← target (data corruption, no hijack — e.g. login leakage)
    [ buffer       ] ← attacker input starts here
    Low addresses (rsp)
    

• •

  Limitations

  • •

    developers are supposed to perform bounds checking; a useful buffer overflow must also be repeatable to reliably compromise a system, which takes time to develop without crashing the target

• •

  When to use it

  • •

    The input operation can write beyond the actual buffer. Check canary placement and other protections separately.

  • •

    Program prints its own raw stack contents before/after your input → you may not need a separate leak primitive; the offsets and secrets are handed to you.

  • •

    An adjacent variable or pointer may be a useful target without changing the saved return address.

• •

  Examples

  • •

    Overflow into an adjacent is_admin variable to change a later access check without changing the return address.

  • •

    If the saved return address is 56 bytes away, b'A' * 56 + p64(win) illustrates a basic ret2win Technique payload.

• •

  pwntools

  • •

    payload = b'A' * offset + corrupting_value
    p.send(payload)
    

• •

  Debugging

  • •

    disas challenge             # find the buffer's rbp-relative offset
    x/40gx $rsp                 # inspect the raw stack after sending input
    

• •

  Variants

  • •

    Adjacent-data corruption (no control-flow hijack): overwrite a variable the program trusts later — a stored password/secret, a flag, a size field — without touching the return address at all.

  • •

    Return-address overwrite (control-flow hijack): see ret2win Technique for the simplest version (jump to an existing function) and Unavailable reference for when NX blocks straight shellcode and no single existing function does what you need.

  • •

    Off-by-one: a boundary error writes one extra byte or element. Its impact depends on the adjacent data.

  • •

    Buffer over-read (reading rather than writing past bounds): the inverse problem — see Memory Disclosure (Info Leak) — often used to leak a canary or address rather than to corrupt anything directly.

  • •

    Unbounded routines and incorrect length calculations can cause overflows. A bounded routine is only safe when given the correct capacity.

• •

  Related

  • •

    Race Condition

  • •

    Stack Frame Layout

  • •

    Stack Canary

  • •

    ret2win Technique

  • •

    Integer Overflow (Signedness Bypass)

  • •

    Unavailable reference

• •

  Cards

  • •

    What is a buffer overflow?

    • •

      Overwriting a memory buffer so data spills into adjacent, unrelated memory areas

  • •

    What's the difference between overflowing into a return address vs. an adjacent variable?

    • •

      Return-address overwrite hijacks control flow (what runs next); adjacent-variable overwrite corrupts data the program trusts later, without changing what code executes.

  • •

    Why did leaking the raw stack make Login Leakage easier than a blind overflow?

    • •

      It handed over the exact offset to the target and its address, removing the need to brute-force or separately leak either one.

◌ Explore connections in Graph view