Kernel Security Transparency

Overview: This page is the status of kernel CVEs on the Root Lock kernel you boot. uname -r is 6.18.9-hs. Kernel 5.19.6 is an archived line. A CVE in an application you run, such as a web server, an FTP server, a database, or a CI server, is outside this list. If that program is on your allowlist, its bug fires in that program.

On this kernel the BPF syscall is off, so there is no eBPF program to load. Each row was read from the published build configuration and the kernel source. No exploit was run to produce these rows.

The long write-ups also print a Score on Root Lock beside the status word. That figure is a CVSS environmental score for one deployment. When the bug can be reached only through a program that has no allowlist entry, that program does not run and the catalog prints 0.0. The catalog also prints 0.0 when the hardware the bug needs is not in the machine. Approving the missing program makes that row Affected. The number for the seven rows below is in the note at the end of this page.

Residuals (non-zero Score on Root Lock)

These seven CVEs are Affected on 6.18.9-hs. The base score is the upstream score. Full write-ups: Compiled-in CVEs. The environmental figure for this table is in the note at the end of this page.

The io_uring CVEs in the catalog are already fixed on 6.18.9-hs. CONFIG_IO_URING stays set, so a later io_uring finding stays on the patch date.

These seven stay on the patch date in your policy. The fix arrives in a Root Lock bundle. A program you already approved can hit a bug in this table. It can read the files it was granted, and it can panic the kernel. It does not start a program that has no allowlist entry. The next boot loads the allowlist saved on disk. Filing the row does not close it.

The Four Assessment Gates

Every entry on this page was checked by reading the build configuration and the kernel source, in this order. Nothing was assumed about what is compiled in, and a scanner result was not taken as the answer. A person checks the row before it is published. The check does not include running an exploit against a Root Lock host. A lab attack test is a separate kind of evidence.

Gate 1 — Is the vulnerable code compiled in? The Root Lock kernel configuration is checked against the relevant CONFIG_ option. If the option is not set, the vulnerable code is not in the kernel you boot. The check stops here as Not affected, whatever the kernel version string says.

Gate 2 — Does Root Lock’s outbound connection control cover the attack path? For a CVE that uses a socket, Root Lock checks outbound connect() calls. A path that reaches the kernel by creating a socket, by sendmsg or recvmsg, or by crypto inside the kernel is outside that check, and the write-up says so.

Gate 3 — Can the program that reaches this bug run? The allowlist is checked on every program start, whether or not Lockdown is on. A program with no allowlist entry does not run. That covers a program the attacker drops, and it covers a bug that can be reached only through a particular program, such as tc or bpftool. If that program has no entry, the catalog prints 0.0. Under Lockdown the allowlist file is immutable, so no new entry can be added after Lockdown. This gate does not apply when the CVE is reached from a program already on the allowlist. A bug in an allowlisted Apache or PHP process is that case: the bug runs inside a program you approved, the row is Affected, and it stays on the patch date. A program you approved runs, including one that arrived in an update you accepted, and it can start only a program that already has an entry. What Root Lock refuses next is a program, a file, or a destination that program was never granted.

Gate 4 — What can root actually do under Lockdown? When a CVE gives an attacker root, Lockdown applies a further limit. The kernel refuses to clear the immutable flag on a file (chattr -i is refused). mount(), fsmount(), and move_mount() are refused. The next boot loads the allowlist saved on disk, so a change that lived only in memory is gone. Clearing Lockdown takes a reboot from the physical console or the serial console onto the maintenance kernel. SSH cannot make that pick. SSH remains how you administer the host before and after that step. Those limits hold on the kernel you boot.

Reading files and reading memory during the live session stay open. Sending the files off the host depends on an approved program that can open a connection, such as curl. The bug can panic the kernel. Firmware, the machine’s management controller, and a physical attack on the boot chain are outside this page. Disk encryption is what protects the data on disk. An Affected entry says so where that is the case.

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 found a kernel version older than the upstream fix and has not checked whether the vulnerable code is in the kernel you boot.

The steps for recording an exception, for the maintenance kernel, and for the published advisory feeds are on CVE Hygiene for Scanners.

Share this section and the Disabled features list with your scanner vendor when you dispute a row. The proof is the published build configuration for the kernel you boot, not the version string. On 6.18.9-hs the file /boot/config-6.18.9-hs is an 11-line stub, so a search of that file does not show whether the option is set. The configuration to use is the one named on Evidence Status.

How to read the backstop sections

On the write-ups, the backstop is the limit that still applies after the bug fires. The write-ups name two controls, and a boot latch sits in front of both.

The allowlist is checked on every program start, whether or not Lockdown is on. A program with no allowlist entry does not run.

The latch is heartsuite-kernel-latch.service. Early in every Root Lock kernel boot, before the network is configured and before sshd starts, it loads the netfilter modules the firewall needs and sets kernel.modules_disabled=1. Root Lock is not running yet in that window, so the allowlist is not what stops those loads. Until the next reboot, a later modprobe stays refused. The latch does not unload a module already in memory. HS_lockdown.sh writes the same setting again, where that setting exists, in case the latch service is masked. OpenRC has no latch service and gets that write only when Lockdown is applied.

For a bug that lives only in a module that was not loaded at boot, the latch is the control the write-up is naming. An option set to =m stays on the patch date. Not affected is the word for an option that is unset. Code built in with =y, and code in a module that did load, is in the running kernel.

Note on Scores on Root Lock and deployment tuning

File the seven rows above as Affected. Score on Root Lock is a second number for one deployment: 7.1 HIGH when the allowlist already includes a program that can send data off the host, such as curl or wget, and 6.1 MEDIUM when you have confirmed that it includes none of those. The row stays on the patch date either way. The detail below is the CVSS environmental vector behind those two figures.

They are published at 7.1 HIGH for an allowlist that already holds an outbound networking utility such as curl, wget, outbound ssh, nc, or python3 with sockets. A live session can read files and send them off the host through that utility, so Modified Confidentiality stays High (MC:H). Modified Integrity is None (MI:N): a new program does not run, the allowlist stays as loaded, and the session ends at reboot. Modified Availability stays High (MA:H) because the bug can panic the kernel. The vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/MC:H/MI:N/MA:H, which is 7.1 HIGH.

If you have confirmed that your allowlist holds none of those utilities, the same vector with MC:L is 6.1 MEDIUM. A live session can read files, and carrying them off the host then takes the console. The published figure stays 7.1 until you have confirmed that.

An allowlist with no process-mutation utilities (kill, pkill, or init-system control beyond what Root Lock itself uses) can treat the userspace part of a disruption as MA:L. A kernel panic does not depend on the allowlist, so the published figure keeps MA:H.

Catalog rows marked fixed on 6.18.9-hs keep the archived 5.19.6 score.

Note on Not-exploitable entries that depend on allowlist composition

A row prints 0.0 when the program that reaches the bug has no allowlist entry. That program does not run, so the path is not reached on a host that has not approved it. Setup Mode fills the allowlist from the programs your services actually run. If you approve the program, file the row as Affected and keep it on the patch date. Not affected stays the word for an option that is unset.

Module loads after boot are the other control: kernel.modules_disabled, written by the boot latch.

• modprobe, insmod, and kmod load kernel modules. On Debian 12 these resolve to kmod. Once the latch has run, a later modprobe stays refused. CVE-2024-36883 stays at 0.0 because no new module can finish its network setup after the latch. The latch does not unload a module already in memory.
• tc (iproute2) changes traffic-control settings. Allowlisting it makes CVE-2025-37914, CVE-2025-37915, CVE-2025-37923, CVE-2025-22121, and the other traffic-control rows Affected.
• bpftool, trace-cmd, perf, and programs that write kernel trace data are kernel instrumentation. Allowlisting them makes the tracing rows, including CVE-2024-38588, Affected.
• dmsetup, raw block-device tools, and cryptsetup mappings created after boot change block storage. Same shape.
• ip xfrm, setkey, strongSwan, libreswan, or any IKE daemon sets up an encrypted network tunnel. Allowlisting any of these makes that path reachable and makes CVE-2026-43284 Affected at its base score of 8.8 HIGH.
• e4defrag, or any extent-defragmentation tool, reaches ext4 online defragmentation. Allowlisting it makes CVE-2024-26704 Affected at its base score of 7.8 HIGH.

If you run a development or debug host and you need one of these tools, file the matching catalog row as Affected. The kernel refuses a program that has no allowlist entry. The tool you approved is itself the way in.