Kernel live patching changed how Linux teams think about critical CVEs. A security fix lands in the running kernel in seconds, and the database server, the SAP host or the hospital system stays up. No outage window, no change-board fight.
But live patching solves one problem: applying a kernel fix without a reboot. It doesn’t tell you which servers are actually protected. It doesn’t stop your vulnerability scanner from flagging them, and it doesn’t remove the reboot forever. In most enterprises it also isn’t one tool. It’s three or four.
This article covers where live patching ends, and how to fit it into the patch and compliance process you already run.
The live patching landscape
| Tool | Covers | Managed from |
|---|---|---|
| Red Hat kpatch | RHEL | Red Hat Satellite, Red Hat Insights |
| Oracle Ksplice | Oracle Linux (UEK and RHCK) | ULN / Oracle Linux Manager |
| Canonical Livepatch | Ubuntu LTS (Ubuntu Pro) | Landscape, Livepatch on-prem |
| SUSE Live Patching | SLES, SLES for SAP | SUSE Multi-Linux Manager |
| Amazon Linux live patching | Amazon Linux 2023 | AWS Systems Manager / dnf |
| TuxCare KernelCare | Many distributions with one agent | TuxCare portal or ePortal (on-prem) |
Most of these come bundled with a subscription you already pay for: kpatch with RHEL, Livepatch with Ubuntu Pro, Ksplice with Oracle Linux Premier Support. A mixed estate that “uses what it already has” ends up with several live patching tools. Each has its own console, and each console sees only its own distribution.
TuxCare’s KernelCare takes the other route: one commercial agent across most major distributions, with an on-prem ePortal for disconnected networks. If you can standardize on a single tool, that’s a strong option. Many teams can’t, because of vendor support contracts, SAP certification on SLES, or a policy of keeping what the OS vendor supports.
Either way, the same four gaps remain.
Gap 1: Your scanner still says the server is vulnerable
Most vulnerability scanners decide whether a kernel is patched by reading its version string. A live patch fixes the running code but doesn’t change the version. So the scanner reports the CVE as open, the security team raises a ticket, and someone has to prove that it’s actually fixed.
Scanner vendors have been adding live patching awareness, but support varies by scanner and by live patching tool. Even Red Hat’s own tooling has shown kpatch-patched systems as vulnerable at times. In a mixed fleet you need one answer for each server: is this CVE closed, by a package update, by a live patch, or not at all?
Gap 2: Most live patches expire
Except for TuxCare’s KernelCare, vendor live patches only cover a kernel for a limited period. After that, the server has to boot into a newer kernel to keep getting fixes.
- Amazon Linux 2023: about 3 months per kernel
- RHEL kpatch: about a year per kernel on current releases
- Ubuntu Livepatch and SUSE Live Patching: about 13 months per kernel
SUSE’s documentation describes live patches as a temporary measure until the next reboot.
So live patching doesn’t remove reboots; it moves them. The question becomes: which servers are approaching the end of their live patch coverage, and when is their next maintenance window? Across four vendors with four different clocks, a spreadsheet won’t keep up.
Gap 3: Live patching covers the kernel, not the rest
A typical Linux patch cycle also includes OpenSSL, glibc, systemd, the database, the Java runtime and third-party applications. Some live patching products cover a few user-space libraries, but most of the patch backlog still needs a package update and often a service restart.
If live patching runs as its own silo, you get two patch processes, two sets of reports and two answers to “are we compliant?”
Gap 4: The agents themselves need managing
Every live patching tool is an agent: installed, enrolled with its management server, kept up to date and kept running. In a large estate, some agents will have stopped, failed to register or drifted to old versions. A stopped agent means no protection, and nobody notices until the scanner or the auditor does.
Live patching inside your patch process: a practical model
The goal isn’t to replace kpatch, Ksplice, Livepatch or KernelCare. Keep the live patching tools that fit each distribution, and put one operational layer above them:
- One inventory. For every Linux server: the distribution, the running kernel, which live patching tool is present (if any), its version, and whether it’s running.
- One compliance view. Package patches and live patches together, so “patched” means the same thing for RHEL, Oracle Linux, Ubuntu and SLES.
- Reboots planned before coverage runs out. Servers that are approaching the end of their live patch coverage go into the next maintenance window automatically, not the next emergency.
- One process for everything else. User-space, application and third-party patches follow the same policies, approvals and reports.
- The same process for air-gapped networks. Disconnected and classified environments get the same workflow as connected ones, with local repositories in place of internet access.
RHEL and Oracle Linux: two ways to handle live patching
A common estate in telecoms, finance and government runs Red Hat Enterprise Linux and Oracle Linux side by side. There are two sound ways to live patch it.
Option 1: Use each vendor’s own tool (kpatch and Ksplice)
- RHEL servers use kpatch. It’s included in the RHEL subscription. Live patches arrive as ordinary RPM packages (kpatch-patch) from Red Hat’s repositories, or from a Satellite or local mirror in disconnected networks.
- Oracle Linux servers use Ksplice. It’s included with Oracle Linux Premier Support. The Ksplice offline client gets its updates as RPM packages from a local ULN mirror, so it also works without internet access.
Why choose it: there’s no extra license, and each OS vendor fully supports its own live patching.
What to plan for: two tools with two different coverage clocks. RHEL kpatch covers each kernel for about a year, so those servers still need a planned reboot into a newer kernel. That’s where one inventory, one compliance view and one maintenance-window plan matter most.
Option 2: Standardize on one tool across both (TuxCare KernelCare)
- One KernelCare agent on both RHEL and Oracle Linux, with TuxCare’s on-prem ePortal serving live patches inside the network.
- One live patching feed and console for the Linux estate, with longer coverage that reduces kernel-upgrade reboots.
Why choose it: one agent, one process and one set of live patching reports across both distributions.
What to plan for: an additional license per server, and a check that a third-party live patching module fits your Red Hat and Oracle support terms. The agent itself also needs deploying, registering with ePortal and keeping healthy on every server.
Which one fits?
| Option 1: kpatch + Ksplice | Option 2: KernelCare on both | |
|---|---|---|
| Extra license cost | None (included in subscriptions) | Per-server subscription |
| Tools to run | Two | One |
| Vendor support | Each OS vendor supports its own | TuxCare supports the live patches |
| Planned reboots | Still needed when kpatch coverage ends | Fewer |
| Air-gapped | Satellite or local mirror, plus ULN mirror | TuxCare ePortal |
In both options, live patching is only the kernel layer. User-space packages, applications, reboot windows and compliance evidence still need one process across RHEL and Oracle Linux.
Where JetPatch fits
JetPatch is built for exactly that layer, for on-premises, hybrid and air-gapped server estates.
- Discovery of live patching agents. JetPatch’s software discovery uses a configurable discovery list. Add kpatch, Ksplice, Canonical Livepatch or KernelCare to it, and JetPatch shows which servers have each tool, its version and whether it’s running, alongside the server’s patch status. No new agent is needed.
- Full agent lifecycle with JetPatch Agent Manager (optional). Teams that want more than visibility can bring a live patching agent under Agent Manager. It’s packaged once with the JetPatch Self-Packager. JetPatch can then deploy it, register it with its management server (for example TuxCare ePortal), run health checks, restart it if it stops, control its resource use, and upgrade or roll it back across the fleet.
- Reboot orchestration. Maintenance windows, maintenance rules, ServiceNow CMDB schedules and emergency (zero-day) remediation plans. Kernels that need a reboot are rebooted on your schedule, not by surprise.
- Linux patch management across distributions. RHEL, Oracle Linux, Rocky, Alma, CentOS, Ubuntu, Debian and SUSE, plus third-party Linux packages, through local repositories that work in fully disconnected networks.
- Compliance reporting. Patch compliance dashboards and missing-patch reports across Linux and Windows from one console.
Live patching keeps your servers running between maintenance windows. JetPatch makes sure those windows, and everything that live patching doesn’t cover, still happen on time.
Frequently asked questions
Does live patching remove the need to reboot Linux servers?
Not permanently. Most vendor live patching covers a kernel for a limited time, roughly 3 to 13 months depending on the vendor. After that, the server needs to boot into a newer kernel. Live patching moves reboots into planned windows rather than eliminating them.
Can I use more than one live patching tool?
Yes. Many enterprises do, because kpatch, Ksplice and Livepatch come bundled with RHEL, Oracle Linux and Ubuntu subscriptions. The challenge is getting one view of protection and compliance across all of them.
Why does my vulnerability scanner flag a live-patched kernel?
Many scanners judge kernel vulnerabilities by the kernel version string, which a live patch doesn’t change. Check whether your scanner supports your live patching tool, and keep evidence of which CVEs each live patch closed.
Does JetPatch replace kpatch, Ksplice, Livepatch or KernelCare?
No. JetPatch works alongside them. It provides the inventory, reboot scheduling, compliance reporting and broader patch management around them. With Agent Manager, it can also manage the live patching agents themselves.
Does this work in air-gapped environments?
Yes. JetPatch runs fully on-premises with local patch repositories. Most live patching tools also offer an offline or on-prem option, such as Satellite, Ksplice offline, Livepatch on-prem and TuxCare ePortal.
