Stack Canary

Updated 13 Sep 2026

• •

  What it is

  • •

    A guard value saved in a protected function's stack frame and checked before return. Overwriting it causes the program to abort instead of using a corrupted return address.

• •

  How it works

  • •

    The function copies a guard, commonly from thread-local storage, into its protected stack frame.

  • •

    Epilogue: reload that slot, compare against the segment-register copy — mismatch calls __stack_chk_fail, which aborts the process instead of returning.

  • •

    In typical Linux/glibc challenge setups, calls reuse a guard rather than generating a fresh value on every call; forked children inherit it.

  • •

    Typical Linux x86-64 canaries have a null low byte, which stops a string-based leak unless that terminator is bypassed.

  • •

    High addresses
    [ return addr  ]
    [ saved rbp    ]
    [ canary       ]  ← must survive unmodified, or the program aborts
    [ local buffer ]
    Low addresses
    

• •

  When to use it

  • •

    Without a canary in the vulnerable function, this particular guard does not block the overflow. Other protections still apply.

  • •

    With a canary, an overwrite crossing its slot must preserve its value or avoid changing it.

  • •

    Forked children can share a canary. Byte-by-byte guessing requires a reliable outcome signal and a stable parent process.

  • •

    A raw over-read can expose canary bytes; a string leak normally stops at its leading null. See Memory Disclosure (Info Leak).

• •

  Examples

  • •

    After a valid leak, include p64(canary) at the canary slot so the return-time check still passes.

  • •

    Forked children may share one canary, allowing repeated byte guesses if a reliable success/failure signal exists.

• •

  pwntools

  • •

    payload = b'A' * canary_offset + p64(canary)
    # Continue with the verified padding and return target.
    

• •

  Debugging

  • •

    checksec
    canary              # pwndbg: show the current canary value directly (local debugging only)
    

• •

  Protections and bypasses

  • •

    Fork oracle: children of a stable parent may share the guard. Test candidate prefixes only when normal completion can be distinguished reliably from failure.

  • •

    Raw leak: a read with an explicit byte count can expose a canary without depending on null termination.

  • •

    Diagnostic leak: a re-entry trigger may reveal the guard through debug output. See Backdoor-Assisted Info Leak (Recursive Self-Leak).

  • •

    Recursive over-read: another active frame may expose useful guard bytes. Confirm boundaries and terminators; see Cross-Frame Buffer Over-Read via Recursion (Nested Frame Leak).

• •

  Related

  • •

    Buffer Overflow

  • •

    ret2win Technique

• •

  Cards

  • •

    Where does the stack canary sit relative to a local buffer and the saved return address?

    • •

      Between them — after the locals, before the saved rbp and return address — so an overflow reaching the return address necessarily passes through (and would corrupt) the canary first, unless disabled or bypassed.

  • •

    Why does a canary's first byte being null specifically defeat string-printing leaks but not all leaks?

    • •

      A typical leading null stops %s output at the canary. Raw reads do not stop there, and a corrupted terminator may allow a string leak to continue.

  • •

    Why can a stack canary be brute-forced against a forking service but not a service that restarts fresh each connection?

    • •

      The canary is fixed once per process at startup; a forked child inherits the parent's unchanged value, so repeated connections to the same long-lived parent see the same canary — a fresh restart each time would re-randomize it, defeating the brute force.

◌ Explore connections in Graph view