Kernel Security Transparency

Overview: Every kernel CVE relevant to Root Lock — what it can do, what it cannot, and why.

The Score on Root Lock column is a CVSS v3.1 Environmental Score for a Root Lock deployment: the risk on this kernel, not the theoretical worst case.

Where the attack surface is absent — hardware not present, trigger not installed, feature not compiled in — the score is 0.0 regardless of Base Score. Where the code path is reachable, Lockdown bounds new execution and sealed-allowlist writes; residual scores stay non-zero.

Scores use CR=M, IR=M, AR=M with no Temporal adjustments.

• Compiled-in CVEs — per-CVE write-ups and the full score table
• Disabled features — compiled-out groups and config gates

CVE Status

Which kernel these scores apply to

Scores apply to the Root Lock kernel: 5.19.6-HeartSuite and 6.18. Compiled-out rows (BPF, FUSE, and similar gates) are the product claim. Where the two lines differ, the entry states both.

Score on Root Lock is a product-specific environmental figure. Compiled-out maps to VEX-style Not Affected. Reachable + Lockdown bounds maps to Affected, mitigated.

What malware can and cannot do on this system

Blocked

• Persistence across reboot. No service, cron job, init script running new code, or kernel module added by the attacker survives a reboot. The allowlist is populated only at boot from your authorized sources; any in-memory tampering is wiped on the next boot.

Supply-chain compromise: contained, not prevented. If malware arrives inside a trusted update, Root Lock does not block it from running — it was authorized. What Root Lock does enforce is the blast radius. The malware cannot launch processes outside the allowlist, cannot reach unallowlisted network destinations, and cannot install additional code. A compromised supplier gets one program slot, not the system.

• New program execution. The kernel refuses to run any program not in the Lockdown allowlist, regardless of root privilege. Backdoors, custom exploit tools, droppers, and post-exploitation frameworks cannot run.
• Kernel module loading post-boot. On Debian 12, modprobe and insmod are symlinks to kmod, which is added to the allowlist during standard Setup Mode via systemd-modules-load.service. Lockdown’s file-access enforcement denies kmod access to /usr/lib/modprobe.d/ by default — module loading fails at the file-read stage before any module can be loaded. Module-based rootkits cannot be installed.
• Allowlist modification at runtime. The runtime allowlist lives in kernel memory and is not modifiable post-boot. The on-disk allowlist file is chattr +i immutable; Lockdown blocks FS_IOC_SETFLAGS so root cannot strip the immutable flag.
• Mounting new filesystems. Lockdown blocks mount(), fsmount(), and move_mount() after boot. Bind-mounts and remounts to shadow allowlisted paths are refused.

Bounded by allowlist composition

• Data exfiltration. Reading data is not constrained — root with kernel-context primitives can read any file. Sending data off-host is bounded by which networked utilities are in your allowlist. Deployments with no outbound networking utilities allowlisted have no in-band exfiltration path.
• Service disruption. Root can panic the kernel via syscall primitives or kill -9 allowlisted services. Availability hardening is a separate control; Root Lock does not prevent denial-of-service.
• Lateral movement. Attackers can pivot through whatever the allowlisted process tree permits, but cannot extend that tree. New processes outside the allowlist do not run.

Under Lockdown the kernel decides, per program, whether it can run, which files it can read or write, and which destinations it can reach. By design, remote root does not change that while the machine is running. The files are immutable. The kernel refuses the write. Recovery is the maintenance kernel via physical or serial-console access.

Out of scope

• Sensitive-data disclosure during the live session. A root attacker can read disk content while the session is active. Confidentiality during the breach is the role of disk encryption, not Lockdown.
• Hardware-level and pre-boot threats. Firmware compromise, baseboard management exploits, and physical attacks on the boot chain are outside the Root Lock attack surface.
• Misconfigured allowlists. If you allowlist tools you should not — modprobe, bpftool, networked exfiltration utilities — outcomes move from “Blocked” to “Bounded” and from “Bounded” to “Allowed.” See the deployment-tuning note.

Residuals (non-zero Score on Root Lock)

These compiled-in paths keep a live residual. Full write-ups: Compiled-in CVEs. Compiled-out groups: Disabled features.

How to read the backstop sections

Root Lock runs two independent kernel-level controls, and the per-CVE entries reference both. They are not peers in a list — one is load-bearing, one is defense-in-depth, and the distinction matters when reading residual risk:

• Lockdown (load-bearing). hs_sandbox_caching.c enforces the SPF allowlist on every execve. This check runs unconditionally — it is not gated by HS_lockdown_state — so it continues to refuse non-allowlisted programs even if an attacker with arbitrary kernel write clears Lockdown. The only Lockdown-conditional behavior in this file is an additional log-file write block; the allowlist match itself is independent.
• Lockdown (defense-in-depth). sys_hs_lockdown_hs() sets HS_lockdown_state = 7. While that atomic is nonzero, kernel/ioctl.c:561,568 returns EPERM on FS_IOC_GETFLAGS/FS_IOC_SETFLAGS (closing the chattr -i path that would otherwise let root strip immutability from the allowlist file), and kernel/namespace.c:4218,4300,4453 returns EPERM on all mount paths. There are five HS_locked_down() check sites total in the kernel — none in fs/ or net/ — so Lockdown is an API-gate layer, not an in-line corruption boundary.

The load-bearing control against persistence and lateral expansion is Lockdown’s allowlist. Even in the worst case where an attacker chains a kernel UAF into arbitrary write and clears HS_lockdown_state, they still cannot run new programs, modify the allowlist, install backdoors, or survive a reboot, because the allowlist check is not on the same state machine. They regain only the ability to mount filesystems and set immutable flags — meaningful but bounded.

Per-CVE entries on Compiled-in CVEs name the bug, then state which of these two layers limits its post-exploitation impact and how.

Why this is unusual

Most kernel hardening tools gate enforcement on a single state variable that an attacker with arbitrary kernel write can clear in one instruction. Root Lock does not work that way. Lockdown’s allowlist is consulted on every execve regardless of Lockdown’s state — there is no kill-switch an attacker can flip. Even in the worst case examined in this catalog, the system continues to refuse new code execution.

Note on Scores on Root Lock and deployment tuning

The Scores on Root Lock published in this catalog assume a worst-case allowlist composition — i.e., that your Lockdown allowlist contains common utilities including networked tools (curl, wget, ssh outbound, nc, python with sockets, etc.). Under that assumption, an attacker who reaches root via one of the Affected CVEs retains a confidentiality impact of HIGH (MC:H) because they can read sensitive data and pipe it out via an already-allowlisted networked utility. This is the conservative, deployment-agnostic floor.

If you run a tighter allowlist, you may legitimately credit a lower MC. Specifically:

• Allowlist contains zero outbound-networking utilities (no curl, wget, outbound ssh, nc, scripting languages with socket access, etc.): MC:L becomes defensible — the attacker can read on disk but has no in-band exfiltration path within Lockdown’s allowlist. Out-of-band (physical-console, side-channel) exfiltration remains possible; that’s why the credit is L, not N.
• Allowlist contains zero process-mutation utilities (no kill, pkill, init-system control surfaces beyond what Root Lock itself uses): MA:L becomes defensible for the disruption-via-userspace component, though kernel-level availability impact (panics, OOM via syscalls) is independent of allowlist composition and keeps MA:H for any CVE that grants kernel-context primitives.

These are deployment-specific reductions and are not baked into the published Scores on Root Lock. If you have hardened your allowlist accordingly, you can recompute your deployment-specific score by adjusting MC and/or MA in the modified vector. The published scores are correct for any deployment that has not affirmatively confirmed the tighter conditions above.

Note on Not-exploitable entries that depend on allowlist composition

Several Not-exploitable entries justify their 0.0 Score on Root Lock with phrasing of the form “X not in allowlist.” These claims are accurate for any Root Lock deployment built through the standard Setup Mode workflow, where the allowlist is populated from production service activity. Utilities not invoked during that workflow would not be added to the allowlist. Specifically, the following utilities should not be allowlisted on a production Root Lock deployment:

• modprobe, insmod / kmod — kernel module loading. On Debian 12, these resolve to kmod, which standard Setup Mode does allowlist; the protection is Lockdown’s file-access enforcement denying kmod access to /usr/lib/modprobe.d/. Granting kmod that access reverts CVE-2024-36883 (and any other module-loading-dependent CVE) to Affected.
• tc (iproute2 traffic control) — qdisc/filter manipulation. Allowlisting reverts CVE-2025-37914 / 37915 / 37923 / 22121 and other NET_SCHED CVEs to Affected.
• bpftool, trace-cmd, perf, debugfs/tracefs writers — kernel instrumentation. Allowlisting reverts the kprobe / tracing / perf CVE cluster (CVE-2024-38588 etc.) to Affected.
• dmsetup, raw block-device tools, cryptsetup mappings created post-boot — block-layer mutation. Same shape.
• ip xfrm, setkey, strongSwan, libreswan, or any IKE daemon — XFRM management. Allowlisting any of these enables XFRM security association setup, making esp_output reachable and reverting CVE-2026-43284 to Affected 8.8 HIGH.
• e4defrag or any extent-defragmentation tool — ext4 online defragmentation. Allowlisting reverts CVE-2024-26704 to Affected 7.8 HIGH.

If you run a development, debug, or instrumentation-heavy deployment and legitimately need any of the above, treat the corresponding Not-exploitable entries as Affected for your environment, and apply the standard Affected backstop logic (Lockdown’s allowlist still refuses unknown programs, but the now-allowlisted utility is itself the trigger). The “Not exploitable” classifications are correct for Root Lock deployments; they are not universal.

Scanner Guidance

When a scanner flags Root Lock for a CVE listed as Not Affected, the result is a version-string match: the scanner has identified a kernel version older than the upstream fix but has not evaluated whether the vulnerable code path is compiled in.

For the full verification workflow (maintenance-kernel exceptions, scanner configuration, audit evidence, and published OSV feeds), see CVE Hygiene for Scanners.

Share this section and the disabled-features catalog with your scanner vendor as the reference for any disputed CVE entry. For a configuration-level proof, confirm the config gate on the Root Lock host:

grep CONFIG_<GATE> /boot/config-$(uname -r)

Replace CONFIG_<GATE> with the config gate listed in the relevant section. An =n result confirms that gate is not compiled into the running kernel.

The Four Assessment Gates

Every entry in this catalog was verified source-first. No assumptions were made about what is compiled in, and no scanner output was taken at face value. The assessment follows four gates in order:

Gate 1 — Is the vulnerable code compiled in? The Root Lock kernel configuration is checked directly against the relevant CONFIG_ option. If the option is not set, the vulnerable code does not exist in the running kernel. The assessment stops here as Not Affected regardless of kernel version string.

Gate 2 — Does Root Lock’s outbound connection control cover the attack path? For socket-based CVEs, Root Lock intercepts outbound connect() calls only. Attack paths that reach the kernel through socket creation, sendmsg, recvmsg, or kernel-internal crypto interfaces are not covered by this control and are noted accordingly.

Gate 3 — Can an exploit program run? Under Lockdown, the program allowlist is made filesystem-immutable. No new program entries can be added. An attacker-dropped exploit program has no allowlist entry and cannot execute. This gate does not apply to CVEs exploitable from within an already-running, allowlisted process.

Gate 4 — What can root actually do under Lockdown? When a CVE achieves root privilege, Lockdown applies a further constraint. The kernel refuses to clear filesystem immutable flags (chattr -i is blocked at the syscall level). All three mount syscall variants are blocked. Clearing Lockdown takes a reboot from physical or serial-console access onto the maintenance kernel. SSH is not enough. Seal and control integrity are product contracts on the pin you run.

The two residual risks that Lockdown does not close are in-memory data exfiltration (reading live process memory) and availability impact (crashing the system). These are noted in affected entries where relevant.