← All rules
SOCLE-CLD-KRN-041// Kernel buildmediumeffective runtime

Disable hibernation

Requires the kernel to be built without CONFIG_HIBERNATION=y, removing suspend-to-disk support.

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.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 1 standard

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

Hibernation (suspend-to-disk) writes the entire contents of RAM, including encryption keys and other secrets, to a swap area on disk, then restores it at resume. An attacker with disk access can read that image, and the resume path can be abused to replace the running kernel with an attacker-controlled image, bypassing Secure Boot and module-signing protections. Building the kernel without CONFIG_HIBERNATION removes both the disk-resident memory image and the kernel-replacement vector.

What Pavois checks

Pavois reads the build configuration of the running kernel, /boot/config-$(uname -r) and the in-memory /proc/config.gz, and confirms CONFIG_HIBERNATION is not set to y. Checking the booted kernel's actual config (rather than a stale /boot/config-* or a masked systemd target) reflects whether suspend-to-disk is truly compiled in.

describe command("C=/boot/config-$(uname -r); if [ -r \"$C\" ]; then cat \"$C\"; elif zcat /proc/config.gz 2>/dev/null | head -1 | grep -q .; then zcat /proc/config.gz; else echo PAVOIS_NO_KERNEL_CONFIG; fi | grep -E '^(CONFIG_HIBERNATION=|PAVOIS_NO_KERNEL_CONFIG)'") do
  its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
  its('stdout') { should_not match(/^CONFIG_HIBERNATION=y$/) }
end

How to verify it is applied

Run grep '^CONFIG_HIBERNATION=' /boot/config-$(uname -r). Expected: no match, or # CONFIG_HIBERNATION is not set, the line CONFIG_HIBERNATION=y must be absent.

Inspect & investigate

Hibernation activity appears in the kernel log: dmesg | grep -i -e hibernat -e 'PM: ' or journalctl -k | grep -i hibernat. On systems where the kernel still supports it, the systemd targets are visible via systemctl status hibernate.target hybrid-sleep.target.

Remediation

No automated remediation: this is a kernel build-time option, not a runtime tunable. Pavois's harden plan is empty. To fully remove the capability you must boot a kernel compiled without CONFIG_HIBERNATION. As an interim runtime mitigation you can disable userspace triggers (systemctl mask hibernate.target hybrid-sleep.target and set HibernateDelaySec/AllowHibernation=no in logind), but that does not remove the in-kernel resume path this rule targets.

Pavois applies this with its own harden engine, the plan below, not a shell script:

resourcekernel_build
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

Disabling hibernation means the machine can no longer suspend-to-disk; on laptops this removes a power-saving and battery-protection feature (suspend-to-RAM still works). On servers and VMs there is no functional loss. Before swapping kernels, confirm the replacement boots and that no workload depends on resuming from hibernation; keep the previous kernel entry in the bootloader as a fallback.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R23direct2.0high

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.

Sources & references

Official standards

ANSSI-BP-028 (2.0) ↗