Learn about the impact of stack buffer overflows
Introduction
Introduction: "Smashing the stack"
Docker Setup
Frame Layout
Stack Buffer Overflow
Redirect control flow
Answers to exercises
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

About this Learning Path

Skill level:  Advanced
Reading time:  2 hrs
Last updated:  13 Aug 2026
Skill level:
  Advanced
Reading time:
  2 hrs
Last updated:
  13 Aug 2026
Author:Kristof Beyls, Arm
Arm IP:Neoverse Cortex-A
Tags: Performance and Architecture Linux Clang C Assembly Runbook
Author:
  • Kristof Beyls, Arm
Arm IP:
Neoverse Cortex-A
Tags:
Performance and Architecture Linux Clang C Assembly Runbook

Who is this for?

This is an advanced topic for software developers interested in understanding how memory vulnerability-based exploits work on AArch64 and how to defend against them.

What will you learn?

Upon completion of this Learning Path, you will be able to:

  • Analyze the stack frame layout to derive which field in user input overwrites the return address stored on the stack.
  • Build a basic end-to-end exploit by changing the return address to an attacker-controlled value.

Prerequisites

Before starting, you will need the following:

  • An Arm computer running linux with Docker installed.
  • Some familiarity with reading and writing basic C code and AArch64 assembly code.
  • Some familiarity with running linux command line commands.
  • Some familiarity with using a gdb debugger.

Summary

AI-assisted

This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
You’ll examine stack buffer overflows on AArch64 using small C programs in a Docker-based Linux environment. First, you’ll configure Clang and GDB, disable address space layout randomization for reproducible stacks, and inspect stack-frame layout. Then, you’ll craft input that overwrites a saved return address, observe redirected control flow, and see how ASLR affects the experiment.

Frequently asked questions

AI-assisted

These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
Why is ASLR disabled in the container, and what happens if it's not?
ASLR randomizes addresses and blocks the reproducible redirection needed for these experiments. The Dockerfile writes a sysctl configuration to disable ASLR so the stack layout and addresses stay predictable.
How do I confirm the container is set up correctly before running the code?
Check that Clang and GDB are available in the container and that /etc/sysctl.d/01-disable-aslr.conf exists. You need these conditions to keep addresses stable across runs.
How do I figure out which input bytes reach the saved return address?
Use the stack-frame exercise to reason from the local buffer to the saved return address and derive the offset. Then, craft input that pads up to that offset before appending the value you intend to write.
What result should I expect to confirm the overflow behavior before redirecting control flow?
You should observe that writing past the end of the local buffer affects data beyond that buffer, including the saved return address.
What should I check if the redirect-control-flow example crashes instead of running the intended path?
Re-check the calculated offset and the exact bytes you wrote for the target return address. Also ensure the example code matches the provided text and that ASLR is disabled as configured in the container.
Next