How long each Root Lock kernel is maintained

Overview: How HeartSuite maintains, patches, and delivers the Root Lock kernel under subscription — LTS strategy, coordinated update bundles, and how that differs from distribution-vendor errata programs such as RHEL.

Audience: Procurement, risk, compliance, and platform teams evaluating Root Lock kernel maintenance alongside existing distribution patching programs.

Related reading: Enterprise Adoption Guide, Updating Root Lock, Kernel Security Transparency, Distro Compatibility Matrix, CVE Hygiene for Scanners.

What this policy covers

This policy describes how HeartSuite supports the Root Lock kernel — the custom-built Linux kernel that Root Lock by HeartSuite requires for Lockdown enforcement — under a commercial subscription.

It applies to:

• Root Lock kernel streams currently shipped and supported:
  • 6.18 — primary LTS stream and commercial baseline (HeartSuite v1.6.4 ships kernel 6.18.9).
  • 5.19 — legacy stream for existing deployments; no longer the default for new installations.
• Coordinated update bundles that deliver the Root Lock kernel together with matching userspace components (Dashboard, daemon, tools, and installer). Kernel changes are not published or supported as standalone kernel-only packages outside these bundles.
• Integration with subscription terms — patch targets, notification channels, and binding service-level commitments appear in your subscription agreement. This page states public targets and operational boundaries so buyers can align internal change-control and vulnerability-management programs before contract signature.

Note: This policy does not replace the subscription agreement. Where this page and your agreement differ, the agreement controls.

LTS-only strategy

HeartSuite’s current commercial baseline is a mainline LTS kernel (6.18). New streams are LTS bases — not arbitrary upstream version chasing.

The 5.19 stream is a legacy exception: 5.19 was a short-lived mainline release. It remains in this policy only for existing deployments until the deprecation window closes.

Why LTS-only

• LTS branches receive upstream security and stability maintenance for a defined period, which gives HeartSuite a predictable rebuild base.
• HeartSuite’s security model depends on a fixed, published kernel configuration (compiled-out subsystems, enforcement hooks, and Lockdown integration). Rebuilding on a known LTS tag preserves that contract while absorbing upstream fixes that apply to the compiled-in code paths.
• Chasing every upstream minor release would multiply validation cost without improving the enforcement properties buyers adopt Root Lock for.

Commercial baseline

• New subscriptions and new fleet images should standardize on the 6.18 stream.
• HeartSuite v1.6.4 (April 2026) established 6.18.9 as the commercial release baseline for multi-distribution support.

When HeartSuite advances the LTS base (for example, a future move within the 6.18 LTS line or to a subsequent LTS series), customers receive advance notice and migration bundles as described under Customer notification and 5.19 stream deprecation.

How HeartSuite differs from the distribution-vendor model

Enterprise Linux distributions such as RHEL follow a frozen-base, backport-within-base model. The upstream kernel version number visible in uname stays on a vendor branch for years, while individual CVE fixes are cherry-picked onto that branch. Vendor errata, advisory identifiers, and scanner feeds are built around that model.

HeartSuite follows a different model, aligned with how Root Lock is built and validated:

HeartSuite is honest about the trade-off: the Root Lock kernel is not a drop-in substitute for a distribution kernel in every operational sense. It is the enforcement kernel for Lockdown.

The distribution maintenance kernel remains on the system for maintenance and recovery. Distribution errata still apply to packages and to the maintenance kernel path.

For deployment implications, coexistence with distribution maintenance, and fleet patterns, see the Enterprise Adoption Guide.

Root Lock kernel version string anatomy

The running kernel version is shown by uname -r. On a Root Lock deployment, the string identifies the HeartSuite build, not a distribution errata package.

Fielded 6.18 pin: uname -r is 6.18.9-hs. Packaging label is 6.18.9-HeartSuite-3 (build #37). Absence of the word HeartSuite in uname -r does not mean you are on the maintenance kernel.

Legacy 5.19 example: 5.19.6-HeartSuite-1.0

On 6.18 the HS-vs-maintenance test is uname -r plus file on vmlinuz, as documented in Evidence Status. The fielded pin is 6.18.9-hs.

What the version string does not mean

Procurement and scanner teams trained on distribution errata often misread custom kernel strings. The Root Lock kernel version string does not imply:

• Full upstream parity — The string does not assert that every fix present in a newer upstream kernel is backported. HeartSuite rebuilds on the LTS base with the published HeartSuite configuration; fixes apply to compiled-in paths or are addressed through structural absence and Lockdown bounds as documented on the Kernel Security Transparency page.
• Distribution errata equivalence — A match against a distribution CVE feed or rpm -q kernel version is not valid for the Root Lock kernel. The Root Lock kernel is not the distribution enforcement kernel.
• Scanner “fixed in version” logic — Vulnerability scanners that compare uname -r to NVD “fixed version” thresholds will produce false positives for Root Lock kernels. Use HeartSuite’s per-CVE status and CVE Hygiene for Scanners guidance instead of raw version-string matching.
• kABI or DKMS compatibility — The string does not promise binary compatibility with out-of-tree kernel modules built for the distribution kernel or for prior HS builds.
• Live-patch level — There is no parallel “kpatch level” or running-patch suffix; updates require a coordinated bundle and reboot path.
• Secure Boot readiness — Version format does not indicate UEFI Secure Boot signing status for the Root Lock kernel entry. Secure Boot support for the Root Lock kernel remains incomplete; see the Enterprise Adoption Guide for current status.

For independent verification of what is in the build, HeartSuite publishes the kernel .config SHA-256 and evidence packs for each supported stream.

Update delivery

Root Lock kernel updates are delivered only as part of coordinated HeartSuite release bundles.

Bundle format and integrity

• Updates ship as a self-extracting heartsuite-install.sh bundle with a published heartsuite-install.sh.sha256 checksum file.

• Before execution, verify integrity:

  sha256sum -c heartsuite-install.sh.sha256
  

  Expected output: heartsuite-install.sh: OK

• Each bundle updates the Root Lock kernel, userspace tools, Dashboard files, and GRUB defaults together so the enforcement stack stays paired and tested.

Applying an update

The installer will not overwrite Root Lock while that kernel is booted.

1. If Lockdown is applied, unseal from the console first. That trip is not the install boot.
2. From a terminal in Setup Mode, run bash heartsuite-install.sh and type YES. That takes one stock or maintenance boot and continues the update. The default stays Root Lock.
3. If you are already on the original distro kernel or the maintenance kernel and Lockdown is not applied, run the installer. There is no YES step.

Root Lock is not loaded on that stock or maintenance boot: it does not block, log, or take backups. Choose a time when that gap is acceptable.

Full step-by-step procedures, failure recovery, and Lockdown considerations are in Updating Root Lock.

Pre-configured image alternative

Teams that provision from images may reprovision from an updated pre-configured image instead of in-place bundle application. This is equivalent from a support perspective when the image contains a bundle version HeartSuite has published for that stream.

Image pipelines should pin bundle version, checksum, and Root Lock kernel string in build metadata for audit traceability.

In-place bundle application after Lockdown still needs the console unseal on that host. Teams that will not open a console on every node should treat image reprovision as the fleet path. Package installs on a live sealed host are a different job — Protecting During Maintenance.

Patch commitment tiers

HeartSuite classifies kernel-related security work using the reachability model on the Kernel Security Transparency page. The tables below are public targets for coordinated bundle delivery. Binding SLAs — including business-day definitions, escalation, and credit terms — are set in your subscription agreement.

Clock start for timed tiers: HeartSuite confirmation that the issue applies to the supported Root Lock kernel stream (reachable path or required rebuild), based on upstream vendor/public confirmation and HeartSuite analysis.

Notes

• Many high-severity CVEs are Not Affected on Root Lock kernels because the attack surface was never compiled in. Those entries do not consume patch-tier clocks.
• For reachable CVEs, Lockdown limits persistence and arbitrary code execution even before a rebuild ships; patching remains part of defense-in-depth and subscription commitments for reachable paths.
• HeartSuite does not commit to per-CVE errata identifiers in the distribution-vendor style. Bundle manifests list addressed CVEs for the release.

Customer notification

HeartSuite notifies subscription customers through the following channels:

Major stream deprecation: HeartSuite provides at least 30 days’ advance notice before ending support for an Root Lock kernel stream (for example, end of 5.19 support). Notice includes migration bundle availability and recommended maintenance windows.

Machine-readable advisory feeds are published as JSON under /advisories/ on each annotated hs-v* release tag.

For the current release (hs-v1.6.4-kernel-6.18.9, gate_status: PASS): CONFIG-gate Not-Affected SBOM at /advisories/hs-cve-config-sbom.json, OSV at /advisories/osv.json (279 entries), and CycloneDX SBOM at /advisories/sbom.cyclonedx.json.

OVAL XML for OpenSCAP is not yet published. Use the JSON feeds, CVE transparency page, bundle manifests, and email advisories as authoritative sources. Feed URLs and schemas: Supply Chain and Advisory Feeds.

5.19 stream deprecation

The upstream 5.19 branch is end-of-life. HeartSuite no longer recommends 5.19 for new deployments or new pre-configured images.

Support window for existing deployments

• HeartSuite continues to ship 5.19 migration and security bundles for deployments already on the 5.19 HS stream through end of calendar year 2026, subject to subscription status.
• After that date, 5.19 Root Lock kernel support ends unless extended terms are agreed in writing. Email support@heartsecsuite.com before the cutoff to plan fleet migration.

Migration path

1. Schedule maintenance using Updating Root Lock (or reprovision from a 6.18 pre-configured image).
2. Apply the published 5.19 → 6.18 migration bundle for your distribution and HeartSuite version.
3. Reboot into the 6.18 Root Lock kernel, review Dashboard queues for any new program activity, and re-engage Lockdown if required.
4. Update vulnerability-management and configuration baselines to reference the new version string and published 6.18 config hash.

Functional differences between streams (configuration, module footprint, CVE tables) are summarized in the Distro Compatibility Matrix and stream-specific evidence materials.

Support boundaries

Subscription scope

• The Root Lock kernel is included in the Root Lock subscription. There is no separate kernel-only support contract.
• Incidents, rebuild requests, deployment guidance, and coordinated updates for kernel behaviour are handled under the same subscription that enables Lockdown.
• Verification artifacts (config SHA-256, evidence packs, CVE transparency data, bundle checksums) are provided as part of the product documentation and subscription deliverables.

Coexistence with distribution subscriptions

On a host running Root Lock:

Root Lock replaces the enforcement kernel for protected operation; it does not remove the distribution kernel or cancel distribution maintenance obligations on the maintenance-kernel path. During maintenance on the maintenance kernel, the host behaves as a standard distribution system without Lockdown enforcement.

Distribution-vendor subscriptions (RHEL, SLES, Ubuntu Pro, and similar extended-support offerings) and third-party agents that require the distribution kernel for full functionality continue to apply to the maintenance-kernel path and to userspace packages.

Agents or tools that require BPF, specific kernel modules, or kernel interfaces absent from the Root Lock kernel should run on a kernel that still exposes those interfaces, or on a separate host.

The Root Lock kernel omits these by design to eliminate bypass primitives and attack surface. See the Enterprise Adoption Guide compatibility section and Reduced Kernel Footprint.

What Root Lock does not provide

Root Lock does not offer the following on the Root Lock kernel path:

If a workload requires live patching, vendor-certified unchanged distribution kernels, or broad third-party kernel module support as non-negotiable constraints, evaluate the maintenance-kernel path, HJFS on a standard kernel, or layered controls described in the Enterprise Adoption Guide rather than the Root Lock kernel.

Related reading

• Enterprise Adoption Guide — Deployment, fleet operations, Secure Boot status, risk ownership, and compatibility decision tree.
• Updating Root Lock — Bundle verification, update procedure, and recovery.
• Kernel Security Transparency — Per-CVE status, Not Affected rationale, and Score on Root Lock.
• Distro Compatibility Matrix — Supported distributions, kernel streams, and coexistence notes.
• CVE Hygiene for Scanners — Resolving scanner false positives against HS version strings.
• Supply Chain and Advisory Feeds — Published CONFIG SBOM, OSV, and CycloneDX feeds; GPG/cosign and OVAL roadmap.
• Evidence Status — Per-stream config hash and checker publication status.

This page is procurement- and operations-facing. Patch targets are goals for planning; binding commitments are in your subscription agreement. Last updated: 2026-06-23.