Source article: August 2026. This technical explanation uses Linux as an example. It is not a guarantee against memory errors or an instruction to disable production safeguards.
What ASLR does
Address Space Layout Randomization places many virtual addresses at random offsets when a program starts. Fixed library, stack and executable-code addresses become less reliable for an attacker. The underlying memory vulnerability remains; ASLR is an additional layer that makes repeatable exploitation harder.
Depending on the kernel configuration, Linux randomises the memory-mapping base, stack, VDSO, shared libraries and position-independent programs. The more extensive mode also randomises the heap.
Read the Linux setting correctly
Inspect the current system-wide mode without changing it: sysctl kernel.randomize_va_space.
0: address-space randomisation is disabled.1: randomises the memory-mapping base, stack, VDSO, shared libraries and PIE programs.2: also randomises the heap.
Defaults also depend on kernel configuration. A read-only query is enough for an inventory. Globally disabling protection is not an appropriate diagnostic step on production systems.
Why the main executable needs PIE
The main program can load at changing addresses only when built as position-independent code. GCC provides -fPIE or -fpie, while the linker uses -pie to produce a Position Independent Executable. Distributions and build systems may enable this by default; inspect the actual delivered build.
A minimal build for your own test program is cc -fPIE -pie -o demo demo.c. ELF Type: DYN is a useful clue but also describes shared objects. Consider file type, ELF header and program headers together.
Read-only checks
- Record
sysctl kernel.randomize_va_space. - Inspect your binary using
readelf -hW /path/to/programandreadelf -lW /path/to/program. - Check compiler and linker flags in the reproducible build log, not only an arbitrary local binary.
- Compare memory maps across restarts of your own test process without changing other processes or production protection settings.
One changing address does not prove sufficient entropy or resistance to exploitation. A stable address does not automatically mean ASLR is entirely off: non-PIE executables and fixed mappings need separate consideration.
Defence in depth
Fix memory defects, update dependencies and minimise process privileges. Complementary compiler, linker and runtime protections and reduced disclosure of addresses provide further layers. Information leaks can weaken ASLR. A single passing check cannot replace code review, hardening or patch management.
- Check ASLR and PIE on the target system and published build.
- Do not globally weaken protection for convenient debugging.
- Record OS, architecture, kernel and build versions.
- Fix memory-safety defects rather than only making exploitation harder.