Comparing KernelCare
to Red Hat kpatch

Most enterprise Linux vendors now ship a live patching tool, and Red Hat’s is kpatch, built into RHEL back in 2014. Its upstream open-source project, though, is now deprecated. kpatch applies kernel fixes to a running server, so security updates no longer have to wait for a maintenance window.

The problem is how little it covers. kpatch patches only about 10% of the CVEs that affect a system, skipping userspace entirely, and its coverage expires after about a year per kernel, forcing the very reboots live patching was meant to eliminate. On top of that, such narrow protection still rides on expensive RHEL subscriptions.

TuxCare’s KernelCare was built to avoid those gaps. It patches every kernel CVE regardless of severity, extends to OpenSSL and glibc via LibCare, and provides continuous coverage without forced reboots, all for just $50 per system per year. The comparison below breaks down where the two diverge.

	Red Hat kpatch	KernelCare
Supported distributions	Red Hat Enterprise Linux only	Red Hat Enterprise Linux 6, 7, 8, 9, plus Ubuntu, Oracle, AlmaLinux, and many others
Vulnerabilities patched	❌ Only ~10% of CVEs (selected Important and Critical kernel CVEs)	✅ Up to 100% coverage
Coverage for Linux kernel and critical userspace (OpenSSL, glibc)	❌ Kernel only	✅ Yes
ARM64 architecture support	❌ x86-64 only	✅ Yes
Live patching for any running kernel	❌ Select eligible kernels only	✅ Yes
Practically unlimited kernel patching lifetime	❌ About one year per kernel	✅ Yes
Built-in automated patching	❌ No dedicated agent; patches delivered as RPMs, applied via yum/dnf or Satellite	✅ Agent checks and applies new patches automatically
Live patching for end-of-life OS	❌ Not provided with the paid Extended Life-cycle Support add-on	✅ Red Hat Enterprise Linux 6, 7, plus Ubuntu, Oracle, AlmaLinux, and many others
Rebootless roll-back functionality	❌ With a reboot	✅ Rebootless
Custom patch delivery	❌ DIY with kpatch-build; not delivered or supported as a service	✅ Fully managed
Centralized and air-gapped management	❌ Requires Red Hat Satellite (separate license)	✅ Included (ePortal)
API available	❌ Centralized API requires Red Hat Satellite (separate license)	✅ Included (ePortal)
Single patchset distribution for all patches	✅ Yes	✅ Yes
Actively developed upstream	❌ Deprecated, in maintenance mode	✅ Yes
24/7 support	❌ Severity 1 and 2 only, premium subscribers	✅ Online, 24/7/365
Add-ons	–	LibCare, custom patches
Type of patching	Persistent	Persistent
Cost	Requires an active RHEL subscription: $878.90 (Standard) or $1,428.90 (Premium) per system/year; EUS add-on +$273.90	From $50 per system per year, bulk pricing available

The chart shows where the two diverge. The rest of this comparison unpacks what each difference means for the systems you actually run.

Live patching should cover the systems you actually run, whatever mix of distributions that turns out to be. kpatch is built and maintained by Red Hat developers, so in practice, it is a RHEL tool, and even inside RHEL, RHEL 6 and some RHEL 7 versions fall outside its support. A handful of non-RHEL distributions, such as specific Ubuntu, Debian, and Gentoo versions, are technically supported, but only if you author the live patches yourself, which requires deep kernel expertise and carries real risk if you get it wrong.

KernelCare takes the opposite stance. It live-patches RHEL, Ubuntu, Debian, Oracle Linux, AlmaLinux, Rocky Linux, Amazon Linux, and more out of the box. For a single-distribution shop, that may not seem decisive today, but it means one tool and one workflow if your estate ever grows beyond RHEL.

The whole point of live patching is to quickly fix vulnerabilities, so the first question is which ones a tool actually fixes. Our own research found that kpatch live-patches only about 10% of the CVEs that affect a system, and some of that gap is by design.

kpatch live-patches only the kernel CVEs that Red Hat itself rates Important or Critical, and that bar is narrower than it looks. Red Hat assigns its own severity ratings, which may differ from the score a CVE gets in the National Vulnerability Database, so a flaw rated Critical elsewhere can be downgraded and skipped. Those ratings also assume a typical configuration, so a CVE that Red Hat scores lower can still be a serious exposure in your specific setup, yet it gets no live patch and waits for the next kernel and a reboot. And even among the CVEs Red Hat keeps at Important or Critical, its own documentation says not all are guaranteed a live patch.

KernelCare removes the guesswork by live-patching all kernel CVEs, regardless of severity rating, so coverage does not hinge on how a given CVE was scored.

Live patching should keep the whole system secure without restarts, but kpatch only ever touches the kernel. Every userspace library vulnerability, including the OpenSSL and glibc flaws behind incidents like Heartbleed, GHOST, and Looney Tunables, still waits for a package update and a service or application restart. These libraries sit underneath almost everything you run, so a single glibc or OpenSSL fix can mean restarting much of the stack.

KernelCare closes this gap with LibCare, patching shared libraries like OpenSSL and glibc in memory without restarting the applications that depend on them. Patching critical userspace without downtime is what lets teams meet PCI DSS, SOC 2, and FedRAMP remediation deadlines on systems that cannot be taken offline.

Live patching should protect every server in your estate, not just those on a particular processor. kpatch live-patches x86-64 and ppc64le, which leaves Arm64 systems with no live patching at all. As Arm moves further into the data center and the cloud, that is an increasingly real blind spot.

KernelCare covers both x86-64 and Arm64, so the same rebootless protection applies whether a workload runs on traditional x86 hardware or on Arm.

Live patching should cover the kernel you are actually running, but kpatch only patches a subset of them. It live-patches the kpatch-eligible base errata kernels that Red Hat designates once each quarter, so unless your system is running one of those designated kernels, you get no live patches until you move to one.

KernelCare places no eligibility restriction at all. Whatever kernel is loaded, it patches it, so coverage follows your systems rather than asking them to follow a list.

Even once you are on an eligible kernel, the coverage is time-boxed. Each eligible kernel receives live patches for about a year, after which you have to upgrade the kernel and reboot to keep getting fixes. This is the limitation that quietly defeats the purpose. Instead of removing reboots, kpatch defers them, and you end up planning maintenance windows around the vendor’s calendar anyway.

KernelCare sets no such clock, patching each kernel for a practically unlimited lifetime, so you stay protected on your existing kernel with no forced annual reboot.

Live patching should run quietly in the background, not become another thing to manage. kpatch has no dedicated patch-automation agent. Patches ship as RPMs that you apply through yum or dnf, or push out with Satellite, which means staying current is either a manual administrative task or something you stitch together with general-purpose update tooling.

KernelCare installs a lightweight agent that checks for and applies new patches automatically, and integrates with the IT automation you already use. Once it is deployed, keeping systems patched stops being a recurring chore.

Red Hat does not provide kpatch live patches during the Extended Life Phase, and not even with the paid Extended Life-cycle Support add-on. Once a release reaches end of life, your live patching disappears even if you keep paying for security errata.

KernelCare does the reverse. It continues to deliver live patches for end-of-life distro versions such as CentOS 7, Ubuntu 18.04, Debian 10, RHEL 7, and many others, so the systems you cannot retire on schedule stay protected while you plan the move on your own timeline.

Live patching should be reversible, because occasionally a fix needs to come back out, for instance, when a mitigation carries a performance cost (as some Spectre and Meltdown fixes did) and an alternative mitigation is available.

kpatch cannot do this. Reverting a live patch requires a reboot, turning a problem patch into a planned outage and removing the very benefit that made live patching attractive. KernelCare, on the contrary, lets you roll back any applied patch with a single command and no reboot, so reverting a patch is as low-impact as applying it.

Some environments need a fix the vendor has not shipped, or a patch tailored to their own code. With kpatch, that is a do-it-yourself effort: you build the patch yourself with kpatch-build, with no managed delivery and no support behind it. For most teams, the required kernel expertise is a barrier in itself.

KernelCare offers fully managed custom patches that TuxCare builds, tests, and maintains for you. You get the fix you need without taking on the work and risk of authoring live patches in-house.

At any real scale, live patching has to be managed centrally, and increasingly in environments with no internet access. With kpatch, centralized rollout means standing up a separately licensed Red Hat Satellite, an added cost and one more system to run.

KernelCare includes ePortal, an on-premises private patch server for staged rollouts, controlled deployments, and fully air-gapped networks, at no extra license cost. The capability that costs extra on the Red Hat side is part of the package on the TuxCare side.

Modern patching should be scriptable and tied into the rest of your automation. kpatch offers no native API, so anything API-driven again routes through Red Hat Satellite.

KernelCare includes the ePortal API for registration, management, and Ansible automation, so live patching fits into existing pipelines without a separate management product.

Choosing a patching tool is a long-term decision, so the project’s health matters. The upstream open-source kpatch project is now in maintenance mode, with patch-building moving to klp-build in the mainline kernel. KernelCare, by contrast, is actively developed and commercially supported across distributions and architectures, which is the kind of trajectory you want underneath infrastructure you expect to run for years.

When a patch question becomes urgent, response time matters. kpatch’s around-the-clock support is limited to severity 1 and 2 cases and is available only to premium subscribers, so lower-severity issues wait until business hours. KernelCare includes online 24/7/365 support across subscription levels.

KernelCare Enterprise starts at $50 per system per year for kernel live patching and runs on your existing RHEL systems, with no Red Hat subscription required. Userspace live patching for OpenSSL and glibc is available through the LibCare add-on. kpatch, by contrast, carries no separate fee but rides on an active RHEL subscription, listed at $878.90 for Standard or $1,428.90 for Premium per system per year, with the EUS add-on at $273.90 more to keep live-patch windows open.

The gap is starkest at fleet scale. Kernel live patching for 100 systems is $5,000 a year with KernelCare. Matching it through Red Hat, a RHEL Standard subscription plus EUS, costs nearly $115,280 a year, roughly 23 times more. And even if you treat kpatch as already paid for inside an existing RHEL estate, the EUS entitlements that keep its windows open still add about $27,390 a year.

If you run only RHEL, kpatch can seem like a natural choice, since it’s bundled with your Red Hat agreement. The point of this comparison is that, even on a pure RHEL fleet, the default leaves more uncovered than it appears. Many kernel CVEs and all of userspace go unpatched, the coverage it does provide is limited to Red Hat’s selected base kernels, each patching window runs out after about a year, and even rolling a patch back means a reboot.

KernelCare was built to remove those compromises. It continuously patches the kernel and userspace, regardless of severity, on whatever kernel you are running, and well past its end of life. Rollbacks are rebootless, custom patches are fully managed, and the whole thing runs on your existing systems for a fraction of what Red Hat charges. So whether you run a mix of distributions or want every vulnerability patched without taking systems down, KernelCare is the stronger choice.

Moving from kpatch to KernelCare is straightforward. A single quick-start script installs KernelCare, your systems receive continuous live patching across the board, and existing workloads keep running for as long as you need.

For teams that want to see it first, KernelCare offers a 30-day free trial with full functionality, so you can confirm uninterrupted coverage before committing.