kexec can load an unsigned, arbitrary kernel image
What this means
kernel.kexec_load_disabled is 0 — a process with sufficient privilege can use kexec to load and immediately switch execution to a completely different, unverified kernel image, bypassing secure boot and any measured-boot chain entirely, to survive a reboot with a backdoored kernel. This fires only when kernel lockdown is off: with Secure Boot enabled the kernel runs in lockdown integrity mode, which already refuses an unsigned kexec image regardless of this flag, so the flag is defense-in-depth there rather than a gap — and the rule stays quiet. Rated low because loading a kexec image already requires CAP_SYS_BOOT (root); this hardens against a post-compromise persistence step.
How to fix it
Set kernel.kexec_load_disabled=1 via /etc/sysctl.d/ and run sysctl --system. Note this disables kdump/crash-dump capture and systemctl kexec; and once it is set to 1 at runtime it cannot be returned to 0 without a reboot (the sysctl.d drop-in itself re-applies every boot).
Check it yourself
Run a scan and look for BLWK-KERNEL-008 in the results:
bulwark scanInstalled the standalone CLI package instead of the app? The command is bulwarkctl.
How Bulwark decides
Bulwark reads sysctl_kernel and reports this check when:
kexec_load_disabled == 0 and lockdown == "none"If a value can't be read, Bulwark reports the check as undetermined rather than passing it. View the rule source.
References
Related checks
- Cron entry runs a downloader piped to a shell ·
BLWK-ACCT-001 - Password maximum age is excessively long ·
BLWK-ACCT-002 - Password minimum age is zero ·
BLWK-ACCT-003 - Password hashing rounds are not explicitly configured ·
BLWK-ACCT-004 - Default UMASK is not explicitly configured ·
BLWK-ACCT-005 - A sensitive system file is world-writable ·
BLWK-FS-001