← All rules
SOCLE-CLD-KRN-002// Kernel command lineloweffective runtime

Extend Audit Backlog Limit for the Audit Daemon

Adds the kernel boot parameter audit_backlog_limit=8192 so the audit event queue is large enough to hold messages generated before auditd starts.

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 3 standards

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

audit_backlog_limit sets the queue length for audit events awaiting transfer to the audit daemon. Until auditd is up, all kernel audit messages are buffered in this queue. With the default (small) limit the queue can overflow during early boot, triggering the audit failure action and, more importantly, silently dropping audit records of the earliest boot activity, exactly the window an attacker would target. Raising it to 8192 keeps that early evidence intact.

What Pavois checks

Pavois reads /proc/cmdline, the actual command line the running kernel booted with, and checks for audit_backlog_limit=8192. This beats parsing /etc/default/grub or grub.cfg: those describe what should boot next time, while /proc/cmdline proves the value is in effect right now. A botched update-grub or a competing drop-in would leave the file looking right but the kernel running with the old value.

describe command('cat /proc/cmdline') do
  its('stdout') { should match(/(^| )audit_backlog_limit=8192( |$)/) }
end
describe command("grep -hwsF 'audit_backlog_limit=8192' /etc/default/grub /etc/kernel/cmdline /boot/grub/grub.cfg /boot/grub2/grub.cfg /boot/efi/EFI/*/grub.cfg 2>/dev/null") do
  its('stdout') { should match(/\S/) }
end

How to verify it is applied

Run cat /proc/cmdline and confirm it contains audit_backlog_limit=8192. You can also check grep . /sys/kernel/... is not needed, the live value is whatever booted. After a config change you must reboot for it to appear here.

Inspect & investigate

Backlog overruns and the failure action are visible in the kernel ring buffer: dmesg | grep -i audit (look for "audit: backlog limit exceeded"). Audit records themselves land in /var/log/audit/audit.log; auditctl -s shows current backlog and backlog_limit.

Remediation

pavois harden apply uses the kernel_cmdline resource to add audit_backlog_limit=8192 to the bootloader configuration (GRUB) and regenerate it. Because a kernel boot parameter only takes effect at boot, the change is flagged reboot_required, the value appears in /proc/cmdline only after the next restart.

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

paramaudit_backlog_limit=8192
reboot_requiredtrue
resourcekernel_cmdline
pavois harden plan local

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

Impact & precautions

Low risk: a larger backlog uses a little more kernel memory but does not change normal operation. Precautions: the change requires a reboot to take effect, so schedule it; verify the bootloader regenerated cleanly (/proc/cmdline after reboot) so you do not boot an unintended kernel line. On very memory-constrained systems pick a value consistent with available RAM.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS10.7.2, 6.2.1.4, 6.3.1.3directper OS, see the benchmark tablehigh
NISTCM-6(a)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
PCI DSS10.7.2supporting4.0.1medium

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