Kernel panic on oops
Sets kernel.panic_on_oops = 1 so the kernel halts (panics) immediately on an oops 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 reached an inconsistent, potentially corrupted state. By default the kernel logs the oops and tries to continue, leaving the system running in an undefined state that an attacker may deliberately provoke and then exploit. Setting kernel.panic_on_oops = 1 makes the kernel panic (halt) immediately on any oops, denying the attacker a window to leverage the corrupted state and turning a silent corruption into a fail-stop event.
What Pavois checks
Pavois reads the live kernel value with kernel_parameter('kernel.panic_on_oops') (equivalent to sysctl kernel.panic_on_oops), not a line in /etc/sysctl.d/*.conf. A config file may declare 1 while the running kernel is still 0 because the file was never applied, a boot parameter overrode it, or a later drop-in won. Only the effective parameter proves the kernel's current behaviour.
describe kernel_parameter('kernel.panic_on_oops') do
its('value') { should cmp 1 }
end
describe command("grep -hsE '^[[:space:]]*kernel.panic_on_oops[[:space:]]*=[[:space:]]*1([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run sysctl kernel.panic_on_oops. Expected output:
kernel.panic_on_oops = 1
Inspect & investigate
Confirm the runtime state with sysctl kernel.panic_on_oops. When an actual oops triggers a panic, the panic stack trace is written to the kernel ring buffer, visible via dmesg or journalctl -k before the halt, and captured by kdump if configured.
Remediation
Pavois's harden plan uses the sysctl resource to set kernel.panic_on_oops = 1, persists it in a Pavois-managed drop-in under /etc/sysctl.d/, and applies it live (no reboot). Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| key | kernel.panic_on_oops |
|---|---|
| resource | sysctl |
| value | 1 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: the kernel keeps running after an oops in an undefined, possibly corrupted state, which an attacker can exploit and which can also cause silent data corruption.
Precautions before applying:
- This trades availability for integrity: a single oops that previously left the box limping along will now halt the machine. On systems prone to occasional driver oopses, an unexpected reboot/halt can cause downtime.
- Pair this with
kdump/automatic reboot (kernel.panictimeout) so a panicked host captures a crash dump and recovers, rather than staying down. Validate on a non-critical host first.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R9 | 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.