Kernel panic oops
Requires the running kernel to be built with CONFIG_PANIC_ON_OOPS=y so a kernel oops triggers an immediate panic instead of continuing in a corrupted state.
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
A kernel oops signals that the kernel hit an inconsistent or corrupted state. By default the kernel logs the oops and tries to continue, leaving the system running in a partially corrupted state, which an attacker exploiting a memory-corruption bug can leverage, and which can silently corrupt data. CONFIG_PANIC_ON_OOPS=y turns an oops into an immediate panic (halt/reboot), denying the attacker a second attempt and preventing the system from operating on corrupted state.
What Pavois checks
Pavois reads the build-time config of the running kernel via /boot/config-$(uname -r), falling back to /proc/config.gz, so the result reflects the booted kernel. Pavois expects CONFIG_PANIC_ON_OOPS=y. The behaviour can also be tuned at runtime via the kernel.panic_on_oops sysctl.
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_PANIC_ON_OOPS=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_PANIC_ON_OOPS=y$/) }
endHow to verify it is applied
Build-time: grep '^CONFIG_PANIC_ON_OOPS=' /boot/config-$(uname -r) → CONFIG_PANIC_ON_OOPS=y. Runtime: sysctl kernel.panic_on_oops should return kernel.panic_on_oops = 1.
Inspect & investigate
An oops/panic is recorded by the kernel: review dmesg, journalctl -k, and any crash dumps captured by kdump/kexec (e.g. under /var/crash). The current runtime setting is shown by sysctl kernel.panic_on_oops.
Remediation
No automated remediation for the build flag: CONFIG_PANIC_ON_OOPS is a kernel build-time option. However, the equivalent runtime behaviour can be set with the kernel.panic_on_oops=1 sysctl (a separate sysctl-domain rule), which most distribution kernels honour. Apply the kernel option manually (use a kernel built with it); pavois harden apply cannot change a compiled-in setting.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| resource | kernel_build |
|---|
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Without panic-on-oops, the system keeps running after a kernel fault, risking data corruption and giving exploits room to retry. The trade-off is availability: with it enabled, a non-malicious oops (e.g. a buggy driver) will reboot the machine instead of logging and continuing. Precaution: on systems where uptime is critical, pair this with kdump to capture a crash dump for diagnosis, ensure services restart cleanly on reboot, and avoid it on hosts where a transient driver oops would be more harmful than the reboot. There is no lockout risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R19 | direct | 2.0 | high |
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.