← All rules
SOCLE-CLD-KRN-023// Kernel buildloweffective runtime

Trigger a kernel BUG when data corruption is detected

Ensures the running kernel is built with CONFIG_BUG_ON_DATA_CORRUPTION=y, so detected data-structure corruption triggers a BUG() and stops instead of continuing.

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

CONFIG_BUG_ON_DATA_CORRUPTION=y upgrades the kernel's internal consistency checks (e.g. linked-list and memory sanity validations) from a mere warning to a hard BUG() that halts the offending path the moment corruption is observed. Many kernel exploits work by corrupting in-memory structures; stopping immediately denies the attacker the window to leverage the corrupted state, and prevents a silently damaged kernel from continuing to operate. Without it, detected corruption only logs a warning and execution proceeds, which can let an exploit succeed.

What Pavois checks

Pavois reads the build-time config of the running kernel via /boot/config-$(uname -r) (fallback /proc/config.gz) and asserts CONFIG_BUG_ON_DATA_CORRUPTION=y. Keying on uname -r matches the exact booted image, more reliable than reading a random /boot/config-*. This option depends on CONFIG_DEBUG_LIST and related consistency checks being enabled.

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_BUG_ON_DATA_CORRUPTION=|PAVOIS_NO_KERNEL_CONFIG)'") do
  its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
  its('stdout') { should match(/^CONFIG_BUG_ON_DATA_CORRUPTION=y$/) }
end

How to verify it is applied

Run grep -h '^CONFIG_BUG_ON_DATA_CORRUPTION=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep BUG_ON_DATA_CORRUPTION). Expected: CONFIG_BUG_ON_DATA_CORRUPTION=y.

Inspect & investigate

Static kernel build option, no dedicated log. Inspect with zcat /proc/config.gz | grep BUG_ON_DATA_CORRUPTION or grep BUG_ON_DATA_CORRUPTION /boot/config-$(uname -r). If corruption is detected at runtime, the resulting BUG()/oops and backtrace appear in dmesg and journalctl -k.

Remediation

No automated remediation is shipped: this is a kernel compile-time option. Apply it by booting a kernel built with CONFIG_BUG_ON_DATA_CORRUPTION=y (a hardened or security-oriented kernel), or rebuild the kernel. pavois harden apply cannot change it.

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

Risk if disabled: detected corruption is only warned about and the kernel keeps running, giving an attacker time to exploit the corrupted state.

Precautions before changing it: with this enabled, a genuine corruption now causes a hard stop/panic rather than a warning, which favors integrity over availability, acceptable on security-sensitive hosts but consider it for high-availability nodes. Changing kernels requires a reboot; keep the prior kernel in GRUB as a fallback and validate boot on a console.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R16direct2.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) ↗