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

Enable SLUB debugging support

Requires the kernel to be built with CONFIG_SLUB_DEBUG=y, enabling the SLUB allocator's corruption-detection checks.

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_SLUB_DEBUG=y builds in the SLUB allocator's consistency-checking machinery: redzone and poison checks that detect heap corruption, plus the ability to validate freelist integrity. It is the prerequisite for runtime hardening such as init_on_free/slub_debug and lets the kernel catch use-after-free and overflow conditions instead of silently continuing with corrupted memory. The checks are dormant until requested, so the cost when unused is minimal.

What Pavois checks

Pavois reads the build configuration of the running kernel via /boot/config-$(uname -r) or /proc/config.gz and confirms CONFIG_SLUB_DEBUG=y. Reading the booted kernel's effective config proves the debugging support is compiled into the kernel in use, not just available in some installed image.

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

How to verify it is applied

grep '^CONFIG_SLUB_DEBUG=' /boot/config-$(uname -r) || zcat /proc/config.gz | grep '^CONFIG_SLUB_DEBUG='

Expected output: CONFIG_SLUB_DEBUG=y. To see whether checks are active at runtime, inspect the boot line for slub_debug= with cat /proc/cmdline.

Inspect & investigate

When SLUB debugging detects corruption it prints diagnostics to the kernel ring buffer, inspect dmesg or journalctl -k for messages like Redzone overwritten, Poison overwritten or Object already free. Per-cache state is visible under /sys/kernel/slab/.

Remediation

No automated remediation is shipped: CONFIG_SLUB_DEBUG is a compile-time kernel option and cannot be turned on at runtime. The fix is to boot a kernel built with it enabled, the stock distribution kernels for the supported OSes already do. For a custom kernel, set CONFIG_SLUB_DEBUG=y and rebuild.

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

Without CONFIG_SLUB_DEBUG, the kernel cannot perform allocator consistency checks and you lose the foundation for runtime SLUB hardening, so heap corruption can go undetected. Precautions: enabling the option alone has negligible overhead since checks stay dormant; only activating full checking at runtime (slub_debug=FZP) carries a measurable cost, so reserve that for debugging. Changing kernels requires a reboot, schedule a maintenance window and keep the prior kernel in GRUB as a fallback.

Standards mapping

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