Enable page allocator poisoning
Requires the page_poison=1 kernel boot parameter so freed memory pages are overwritten with a poison pattern, catching use-after-free and scrubbing leftover data.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
Page poisoning writes a known pattern into memory pages as they are freed, so any read or write to a page after it has been freed (or before it is re-initialized) is detected and prevented. This neutralizes large classes of use-after-free vulnerabilities at very low performance cost, and additionally scrubs sensitive data left in freed pages so it cannot leak to the next allocation.
What Pavois checks
Pavois reads the live kernel command line from /proc/cmdline and checks for page_poison=1. It reflects what the running kernel parsed, not /etc/default/grub, a file edit that was never turned into a rebuilt bootloader config would falsely pass a file-based scan while the mitigation is still inactive.
describe command('cat /proc/cmdline') do
its('stdout') { should match(/(^| )page_poison=1( |$)/) }
end
describe command("grep -hwsF 'page_poison=1' /etc/default/grub /etc/kernel/cmdline /boot/grub/grub.cfg /boot/grub2/grub.cfg /boot/efi/EFI/*/grub.cfg 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run cat /proc/cmdline and confirm it contains page_poison=1. Where exposed, the runtime state can be read at /sys/module/page_poison/parameters/... depending on kernel version; the boot line is the canonical proof.
Inspect & investigate
A poison violation surfaces in the kernel ring buffer as a bad page state / corruption report, inspect dmesg | grep -iE 'poison|bad page' or journalctl -k | grep -iE 'poison|bad page'.
Remediation
pavois harden apply uses the kernel_cmdline resource to add page_poison=1 to the bootloader configuration and regenerate it, so the option is present on next boot. A reboot is required to take effect.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| param | page_poison=1 |
|---|---|
| reboot_required | true |
| resource | kernel_cmdline |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Page poisoning carries a small, usually negligible CPU cost for the overwrite on free. Precautions:
- On extremely memory-churn-heavy workloads, benchmark to confirm the overhead is acceptable.
- It can make latent buggy drivers panic when they touch freed pages, surfacing pre-existing corruption rather than causing it; validate on a non-critical node first.
- Applies after reboot only, schedule a maintenance window.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R8 | direct | 2.0 | high |
| NIST | CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.