Ensure ASLR Is Enabled: How to Set kernel.randomize_va_space = 2 on Linux

“Ensure address space layout randomization (ASLR) is enabled” is a CIS benchmark check that fails when the Linux kernel parameter kernel.randomize_va_space is not set to 2, live or in the sysctl files. To fix it, add kernel.randomize_va_space = 2 to /etc/sysctl.d/60-kernel_sysctl.conf, remove lines setting 0 or 1, and run sysctl -w kernel.randomize_va_space=2.

The CIS benchmark lists 2 as the default value, so a failure usually means someone lowered it on purpose, or that the value exists only in memory and not in a file the audit accepts.

What the scanner is actually detecting

This finding comes from a Tenable compliance scan (Nessus or another Tenable product) running a CIS Linux benchmark audit file over an authenticated SSH session. It is a configuration check that reports PASSED or FAILED, not a vulnerability plugin, so there is no CVE behind it. Depending on the audit version, it reads the live value of kernel.randomize_va_space, the sysctl files that set it at boot, or both, and expects 2.

The item number and title change between benchmarks and versions. Some audits split the recommendation into a “- config” item (the files) and a “- sysctl” item (the running kernel), so one host can show two failures for the same setting. Examples from Tenable’s audit library:

Search your report by title rather than item number, because numbering shifts between versions. The fix is the same for every variant.

Real-world risk, stated honestly

ASLR does not fix any bug. It makes memory corruption bugs harder to exploit reliably, because an attacker cannot predict where code and data sit in memory. The kernel documentation defines three values:

• 0: randomization is off. This is also what you get when the kernel is booted with the norandmaps parameter.
• 1: the mmap base, stack and VDSO page are randomized, which means shared libraries load at random addresses. For PIE-linked binaries the code start is randomized too. This is the default only if the kernel was built with CONFIG_COMPAT_BRK.
• 2: everything in 1, plus heap (brk) randomization. This is the default when CONFIG_COMPAT_BRK is disabled.

A host at 0 is meaningfully weaker: every new process starts with a predictable layout. A host at 1 only loses heap randomization, a much smaller gap. Neither is exploitable on its own; an attacker still needs a memory corruption bug in a local or network-facing process. Treat this as cheap defense in depth, and find out why the value was changed, since it often points to a debugging session or install guide that was never undone.

How to confirm it on the host

# 1. Live value (expect 2)
sysctl kernel.randomize_va_space

# 2. Every sysctl file that sets it
grep -Hs 'randomize_va_space' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf 
  /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf

# 3. The files systemd applies at boot, with each file name printed first
/usr/lib/systemd/systemd-sysctl --cat-config | grep -E '^# /|randomize_va_space'

# 4. Boot parameter that turns randomization off
grep -o 'norandmaps' /proc/cmdline

# 5. Ubuntu and Debian hosts with UFW: the extra sysctl file UFW applies
grep '^IPT_SYSCTL' /etc/default/ufw

Two documented ordering rules decide which line wins. Per sysctl.d(5), files must end in .conf, and all files are sorted by file name regardless of directory, so the file whose name sorts last takes precedence. Per sysctl(8), sysctl –system reads /etc/sysctl.conf last, so a value there overrides the drop-in directories. The kernel parameter documentation describes norandmaps as equivalent to writing 0 to /proc/sys/kernel/randomize_va_space.

How to fix it

Step 1: comment out lines that set 0 or 1

For each file the grep in step 2 listed with a non-2 value, comment the line out. For example:

sudo sed -ri 's/^s*kernel.randomize_va_spaces*=s*[01]b/# &/' /etc/sysctl.conf

Do not edit files under /usr/lib/sysctl.d, which belong to packages. sysctl.d(5) reserves /etc for the administrator and recommends overriding vendor settings with a file in /etc/sysctl.d whose name sorts later.

Step 2: set the value persistently

printf 'kernel.randomize_va_space = 2n' | sudo tee -a /etc/sysctl.d/60-kernel_sysctl.conf

This is the file name used in the CIS remediation text. The command appends, because other CIS kernel settings often live in the same file; if it already contains a randomize_va_space line, edit that line instead of adding a second one.

Step 3: apply it to the running kernel

sudo sysctl -w kernel.randomize_va_space=2
sudo sysctl --system

The second command reloads every configuration file and prints what it applies. If the last kernel.randomize_va_space line in its output is not 2, a later file is still overriding yours.

Step 4: remove norandmaps from the kernel command line (if present)

On Red Hat Enterprise Linux and its rebuilds:

sudo grubby --update-kernel=ALL --remove-args="norandmaps"

On Debian and Ubuntu, delete norandmaps from GRUB_CMDLINE_LINUX and GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, then run sudo update-grub. Either way, this part needs a reboot.

Step 5: hosts running UFW

If the file named by IPT_SYSCTL (normally /etc/ufw/sysctl.conf) sets kernel.randomize_va_space to anything other than 2, comment that line out. The CIS Debian 12 remediation warns that a UFW update may restore the entry, so recheck it after package updates.

How to verify the fix and rescan

1. Run sysctl kernel.randomize_va_space and confirm it prints 2.
2. Confirm randomization is active. Run this twice; the stack and heap addresses should differ between runs:

   grep -E 'heap|stack' /proc/self/maps

3. Reboot once if you can, then repeat step 1. Boot is when every sysctl file is reapplied, so this proves no later file puts the old value back.
4. Rerun the same compliance scan with the same audit file and credentials. If the scan cannot read /etc/sysctl.d or run sysctl, see our guide to configuring SSH and sudo credentials for Linux authenticated scans.

What can break and how to roll back

For almost every system, nothing. The kernel documentation says only a few legacy applications, such as some ancient versions of libc.so.5 from 1996, break when the start of the brk area is randomized, and that no known non-legacy applications break this way.

• One legacy program misbehaves. Do not lower the setting for the whole host. setarch(8) can start a single program with randomization disabled (the ADDR_NO_RANDOMIZE personality flag): setarch “$(uname -m)” -R /path/to/program. Put that in the program’s start script or service unit and document it as an exception.
• Running processes keep their layout. A process’s memory layout is chosen when it starts, so services started while the value was 0 stay unrandomized until they restart. Restart long-running services or plan a reboot.
• Rollback. Remove the line from /etc/sysctl.d/60-kernel_sysctl.conf, uncomment any lines you disabled, and run sudo sysctl -w kernel.randomize_va_space= followed by the previous value. No reboot is needed.

Common false positive reasons

• Half-applied fix. Running only sysctl -w passes the live check but fails the file check; writing only the file does the opposite until the next boot. Both are real gaps, not false positives, but they explain a “fixed” host that still fails.
• Relying on the kernel default. A host can show 2 live without any configuration line. Audits that check the files still fail it until you add the explicit line.
• Wrong file name. A file in /etc/sysctl.d without the .conf extension is ignored at boot.
• A later file wins. Your line is correct, but a file that sorts after it, /etc/sysctl.conf, or the UFW sysctl file sets 0 or 1. The live value looks fixed now and reverts at the next boot.
• Scanning inside a container. Containers share the host kernel, so this value reflects the host. Fix it on the host, not in the image.

FAQ

Is kernel.randomize_va_space = 1 good enough?

Not for CIS, which requires 2. Value 1 randomizes the stack, mmap regions and shared libraries but does not add heap (brk) randomization.

Do I need to reboot after the change?

No. sysctl -w takes effect immediately for new processes. A reboot is only needed to remove norandmaps, and it is useful to prove the setting survives boot and to restart processes that started while randomization was off.

The live value is already 2. Why does the check still fail?

Usually because no sysctl file sets it explicitly, or because a file sets a different value that has not been applied yet. Run the checks above, add the line from step 2, and rescan.

Can I turn ASLR off temporarily for debugging?

Yes, but scope it to the process you are debugging with setarch -R instead of changing the sysctl. Host-wide changes made “temporarily” are a common reason this finding appears in the first place.

Tracking this finding across many hosts

On a large Linux estate, the recurring problem is the host where a later sysctl file or a boot parameter brings the old value back. SITEY, a self-hosted vulnerability management platform, imports Nessus results when you upload a .nessus export (they are not pulled automatically). Its AI can draft a host-specific remediation script that runs only after human approval, is deployed by its agents on Linux endpoints, and is followed by a re-test to verify closure.

Sources

• Tenable: CIS Debian Linux 11 Server L1, 1.5.1 Ensure address space layout randomization (ASLR) is enabled – config
• Tenable: CIS CentOS Linux 8 Server L1, 1.5.3 Ensure address space layout randomization (ASLR) is enabled
• Tenable: CIS Debian Linux 12 L1 Server, 1.5.9 Ensure kernel.randomize_va_space is configured
• Linux kernel documentation: /proc/sys/kernel, randomize_va_space
• sysctl.d(5): configuration directories and precedence