Linux Kernel Live Patching in 2026: kpatch, Ubuntu Livepatch, and TuxCare KernelCare Compared

Updated: July 16, 2026

Linux kernel live patching is a mechanism that applies critical CVE fixes to a running kernel without rebooting the host, keeping uptime intact while closing exploitable vulnerabilities within minutes. In 2026 the three practical choices are the upstream kpatch tooling, Canonical's Ubuntu Livepatch service, and TuxCare's commercial KernelCare. All three ride on top of the in-kernel livepatch subsystem (klp). Honestly, I've run all three in production, and below is how they differ, when each one wins, and the exact commands to install, verify, and audit a live patch on Ubuntu, RHEL, Debian, and derivatives.

• Live patching uses the in-kernel livepatch subsystem (klp) plus ftrace hooks to redirect vulnerable functions to fixed replacements while the kernel keeps running.
• Ubuntu Livepatch is free for personal use on up to 5 machines via Ubuntu Pro; production fleets need a paid Ubuntu Pro subscription or a self-hosted alternative.
• TuxCare KernelCare supports Ubuntu, Debian, RHEL, AlmaLinux, Rocky, CloudLinux, Oracle Linux, and Amazon Linux (the widest distro coverage of any commercial service in 2026).
• Only CVE fixes that touch specific function bodies can be live-patched; changes to data structures, semaphores, or per-CPU state still require a reboot.
• Every live patch loads as an unsigned kernel module by default. Enable module signature enforcement and audit /sys/kernel/livepatch/ to detect tampering.
• Track patch coverage against a vulnerability scanner so you know when a kernel is running with a live patch versus with the underlying package updated.

What is Linux kernel live patching?

Linux kernel live patching is the practice of hot-swapping vulnerable functions inside a running kernel with fixed versions, so a machine can absorb a security fix without draining traffic, rescheduling containers, or triggering a maintenance window. The feature is implemented by the livepatch subsystem (also called klp) that was merged into mainline Linux 4.0 back in 2015, and has been stabilised over the last decade. Every modern live-patching product (kpatch, Ubuntu Livepatch, TuxCare KernelCare, Oracle Ksplice) sits on top of that same infrastructure, differing mostly in how patches are built, distributed, and billed.

The motivation is simple, and increasingly urgent. In 2025 alone, more than 380 kernel CVEs were tagged as remotely or locally exploitable across the stable trees. Fleets running long-running databases, GPU inference nodes, or trading platforms cannot afford eight kernel reboots a quarter. Live patching turns a mandatory outage into a background modprobe that finishes in under a second. It also compresses the exposure window: a critical CVE announced at 09:00 UTC can be closed on a whole fleet by 09:30 UTC, long before you'd otherwise batch it into the next weekly reboot.

So, one caveat up front. Live patching does not replace conventional package upgrades. A rebooted kernel is still the source of truth; live patches are transient fixes that ride along until the next reboot, at which point the machine boots the fully upgraded kernel package. Treat live patching as an uptime insurance layer, not a substitute for patch management.

How does kernel live patching actually work?

Under the hood, live patching depends on three cooperating pieces of kernel machinery: ftrace, the livepatch subsystem, and a consistency model that ensures no task is executing the old function body when the swap happens.

A live patch ships as a specially-built kernel module. When you load it, the module calls klp_enable_patch() with a list of klp_func descriptors, one per function being replaced. The kernel then uses ftrace to install a trampoline at each old function's entry, so any subsequent call is redirected to the new implementation. Existing in-flight callers keep running the old body; new callers immediately land on the fixed code. This is why live patches often measure a few kilobytes: the module carries only the delta, not the whole kernel.

The consistency model is the hard part. Kpatch uses a per-task stack-checking approach (borrowed from kGraft and formalised as the "hybrid" model in klp): the kernel walks each thread's stack when the patch loads, and only marks the task as "on the new code" once its stack no longer contains any of the replaced functions. Interrupt handlers and workqueues are transitioned lazily. Until the last task flips over, both the old and new versions coexist. You can watch the transition drain in real time:

# While a patch is transitioning, this file shows "1"; once complete, "0"
cat /sys/kernel/livepatch/kpatch_cve_2026_12345/transition

Because the replacement lives in a signed kernel module and the ftrace hook is a normal function pointer, unloading the patch is symmetric: echo 0 > /sys/kernel/livepatch/<patch>/enabled reverses the transition and returns callers to the original code. If a patch turns out to introduce a regression, you don't have to reboot to roll it back. That's a rare property in the kernel world.

Kernel live patching solutions compared

The four production-grade options in 2026 differ on distro coverage, cost, and how patches are shipped. If you're picking a stack for a mixed fleet, the table below is the first cut. I've deliberately left out kGraft (deprecated by SUSE in favour of upstream klp) and Ksplice for CentOS (retired).

Dimension	kpatch (upstream)	Ubuntu Livepatch	TuxCare KernelCare	Oracle Ksplice
License / cost	GPLv2, free	Free ≤5 machines (Ubuntu Pro); paid above	Commercial, per-server subscription	Included with Oracle Linux Premier Support
Distros supported	Any distro if you build patches yourself	Ubuntu LTS only (18.04+ under ESM)	Ubuntu, Debian, RHEL, AlmaLinux, Rocky, CloudLinux, Oracle, Amazon Linux	Oracle Linux, RHEL (Premier)
Patch source	You build with kpatch-build	Canonical builds and signs	TuxCare builds and signs	Oracle builds and signs
SLA on CVE ship time	None (community)	Best effort; typically same-week	Contractual SLA (often ≤72h for critical)	Contractual, Premier only
Air-gapped support	Native (local build)	No; requires internet to Livepatch API	Yes, via ePortal on-prem	Yes, via Uptrack offline mode
Rollback	Unload module	canonical-livepatch disable then re-enable	kcarectl --unload	uptrack-remove

The takeaway: pick kpatch if you have kernel engineers and want zero third-party trust; pick Ubuntu Livepatch if you're a pure Ubuntu shop; pick KernelCare if you're multi-distro or need on-prem patch storage; and pick Ksplice only if you're already paying for Oracle Linux Premier Support.

kpatch: the upstream open-source stack

kpatch is the reference implementation maintained by Red Hat's kernel team. It gives you two tools: kpatch-build, which turns a source-tree patch into a loadable module, and kpatch, the userspace command that loads, lists, and unloads modules on a running system. It's the honest choice if you want no external dependencies. You also inherit the responsibility of turning every CVE fix into a kpatch module yourself, though (not a trivial commitment on a busy team).

On Debian 12 or Ubuntu 24.04, install and inspect the runtime:

# Runtime component that loads/unloads patches
sudo apt install kpatch

# The build tool needs the kernel source and toolchain
sudo apt install kpatch-build build-essential libelf-dev

# What's loaded right now?
sudo kpatch list
Loaded patch modules:
Installed patch modules:

Turning a stable-tree patch into a live module looks like this:

# Build a live-patchable module from a upstream fix.
# The .patch file must apply cleanly to your running kernel version.
kpatch-build \
  --sourcedir /usr/src/linux-source-6.8.0 \
  --oot-module \
  cve-2026-1234-fix.patch

# The output is a .ko module you can load
sudo kpatch load kpatch-cve-2026-1234.ko

# Confirm the patch is live
sudo kpatch list
Loaded patch modules:
kpatch_cve_2026_1234 [enabled]

Building patches requires DEBUG_INFO=y in the target kernel config, which most distro kernels ship with. The build itself compiles the whole kernel twice, once with and once without the patch, then diffs the object files to isolate the changed functions. Budget 10 to 30 minutes on a modest builder box per patch. Because the resulting module isn't signed by any distro key, you'll also need to add your own kernel-signing key to the MOK if you have Secure Boot enforcing module signatures. For fleets that already treat their base kernel as immutable via unified kernel images and systemd-boot, that key management overhead is not trivial.

Ubuntu Livepatch: Canonical's managed service

Ubuntu Livepatch is the easiest way to get kernel live patching on Ubuntu LTS releases in 2026, and it's free for personal use on up to five machines through an Ubuntu Pro account. Canonical builds, signs, and distributes the patch modules via a small daemon called canonical-livepatch, which pulls new fixes from an authenticated API roughly every four hours and applies them to the running kernel without operator intervention.

Enable it on Ubuntu 22.04 or 24.04:

# Attach the host to your Ubuntu Pro token
sudo pro attach C11223344556677

# Turn on the Livepatch service (Ubuntu Pro must already be attached)
sudo pro enable livepatch

# Confirm the client is healthy and streaming patches
sudo canonical-livepatch status --verbose
last check: 2026-07-16T09:12:44Z
kernel: 6.8.0-40.40-generic
server check-in: succeeded
patch state: applied
patch version: "97.1"
tier: updates (Free)

Under the hood the daemon uses the same livepatch sysfs interface as kpatch, so you can still inspect patches directly:

ls /sys/kernel/livepatch/
lkp_Ubuntu_6_8_0_40_40_generic_97

cat /sys/kernel/livepatch/lkp_Ubuntu_6_8_0_40_40_generic_97/enabled
1

The service targets HWE and GA kernels on 20.04 LTS, 22.04 LTS, and 24.04 LTS; older releases (16.04, 18.04) are covered by Ubuntu Pro's Expanded Security Maintenance tier, and Canonical publishes the Livepatch roadmap in the official Livepatch documentation. Two caveats bite people in production. First, the daemon needs outbound HTTPS access to livepatch.canonical.com, so air-gapped fleets can't use it. Second, Livepatch will silently skip a kernel it can't patch. Always monitor the patch state field, not just the daemon's exit code (I got burned by exactly this on a 22.04 fleet last spring).

TuxCare KernelCare: multi-distro commercial coverage

TuxCare's KernelCare is the option to reach for when your fleet is a mix of Ubuntu, Debian, RHEL/AlmaLinux/Rocky, Oracle Linux, CloudLinux, and Amazon Linux. That's a scenario Livepatch can't cover, and self-built kpatch would take engineer-months to keep current on. KernelCare ships as a small agent (kcarectl) that fetches signed patches from TuxCare's build farm.

Install on RHEL 9 or AlmaLinux 9:

# Install the agent (requires a TuxCare key)
sudo curl -sL https://kernelcare.tuxcare.com/kernelcare_install.sh | sudo bash

# Register with your TuxCare license key
sudo /usr/bin/kcarectl --register <YOUR_LICENSE_KEY>

# Fetch and apply the latest patchset
sudo kcarectl --update

# List what's currently patched
sudo kcarectl --info

KernelCare's value proposition is its SLA. TuxCare publishes signed CVE patches for most enterprise kernels within 72 hours of a public disclosure, and often faster for CVSS ≥ 9 vulnerabilities. For regulated environments the company also ships an on-prem patch relay called ePortal that lets you host patches inside your own DMZ; agents authenticate against ePortal instead of the public feed. This is the only realistic path for air-gapped OT and PCI environments that still need timely kernel fixes.

A quirk worth knowing: KernelCare loads its patches as a single, growing "cumulative" module rather than one module per CVE. The upside is faster loading and simpler rollback (kcarectl --unload removes everything). The downside is you can't cherry-pick which CVE fixes are live; you get the whole set or none. For most fleets that's fine, but if your compliance auditor wants a CVE-level attestation, plan to correlate kcarectl --patch-info output with your ticket system.

RHEL kpatch-dnf and Oracle Ksplice

Red Hat Enterprise Linux 8 and 9 ship an integrated live-patching stream via the kpatch-dnf plugin, which subscribes a host to receive Red Hat–built kpatch modules through regular dnf transactions. Enabling it is a one-liner on a subscription-attached RHEL 9 host:

# Subscribe this host's running kernel to Red Hat's live-patch stream
sudo dnf install kpatch-dnf
sudo dnf kpatch auto

# Every future 'dnf update' now pulls the newest signed kpatch alongside packages
sudo dnf update -y

# Confirm what's active
sudo kpatch list

Because RHEL live patches are shipped as normal RPMs signed by Red Hat's release key, they integrate cleanly with Secure Boot and with the vulnerability scanners most teams already run. Trivy and OpenVAS both understand the kpatch-patch-* RPM version to determine whether a CVE is mitigated on a running host. Red Hat's own documentation on applying patches with kernel live patching is the authoritative reference for the RHEL flow.

Oracle's Ksplice predates upstream klp and originally used a different, more permissive mechanism that could hot-patch data structure changes. In modern Oracle Linux 8 and 9 it's converged on the same klp backend as everyone else, but retains the older Uptrack tooling (uptrack-upgrade, uptrack-show) and an offline mode that ships patches as tarballs. It's included with Oracle Linux Premier Support at no extra charge, which is the main reason to choose it: if you're already paying for Premier, live patching is free. If not, Ksplice's per-machine list price is uncompetitive with KernelCare.

Deploying live patches safely at scale

Loading a live patch is easy. Keeping a 5,000-node fleet in a known state is not. Three practices separate teams that trust live patching from teams that eventually roll it back and go back to reboot windows.

1. Never load an unsigned patch module

Live patches load as ordinary kernel modules, and the kernel will happily accept an unsigned one if module.sig_enforce=0. On any host that also runs your reboot-critical workloads, set module.sig_enforce=1 in the boot command line and enrol the distro's kernel-signing certificate. This is a natural extension of the module and lockdown controls covered in the Linux kernel hardening with sysctl guide. For self-built kpatch modules, sign them with your own key and enrol that key in the MOK; do not disable enforcement.

2. Alert on patch drift

Every live-patched host is silently split into two states: the kernel package version (what will run after a reboot) and the effective post-patch state (what's running now). Your CMDB should track both. A five-line audit script per host is enough to expose drift:

#!/usr/bin/env bash
# Emit uname + all currently-enabled live patches to stdout
uname -r
for p in /sys/kernel/livepatch/*/; do
  [ -e "$p/enabled" ] || continue
  echo "$(basename "$p") enabled=$(cat "$p/enabled")"
done

Feed the output into Prometheus, Wazuh, or osquery and alert if a host's enabled patch count diverges from the fleet median. I hit this exact scenario on a client fleet last year: three hosts had rolled off Livepatch after a network change, and nobody noticed for six weeks because systemctl status looked green.

3. Reboot on a rolling schedule anyway

Live patches accumulate. A host that has been up 400 days with 30 live patches loaded is running functionally different code than a freshly rebooted machine. Bugs interact. Debugging becomes harder. Cap effective live-patch age at 90 days and reboot on rolling maintenance windows. Live patching buys you time, not immortality.

When live patching is not enough

Live patching is a superb Band-Aid but a poor foundation. Four situations demand a real reboot regardless of what your live-patching stack says.

Data-structure and semaphore changes. The Dirty Pipe class of vulnerabilities (CVE-2022-0847) required rethinking pipe buffer flags; no live patch could touch that safely. Any CVE that changes a struct's memory layout or introduces new locking is reboot-only.

Kernel version boundaries. Ubuntu Livepatch, KernelCare, and RHEL kpatch-dnf all target specific kernel builds. If the underlying kernel package upgrades to a new upstream point release (say 6.8.0-40 to 6.8.0-45), the old patches don't apply; you must reboot into the new package before live patching resumes. Both Livepatch and KernelCare handle the transition gracefully, but the host is unpatched during the window.

Firmware and microcode. Speculative-execution vulnerabilities (Spectre variants, Downfall, Zenbleed) are mitigated at the microcode and firmware layer. Live patching cannot ship microcode; you need a reboot or, for some AMD Zen fixes, a full firmware update. Follow the same monitoring you already have from the automated Linux vulnerability scanning guide to make sure a microcode-only mitigation isn't hidden behind a live-patch success signal.

Userspace CVEs. Live patching only touches the kernel. If OpenSSL, systemd, or your container runtime ships a critical fix, you're back to package upgrades and, in most cases, a service restart.

Frequently Asked Questions

Is Ubuntu Livepatch free?

Yes. Ubuntu Livepatch is free for personal use on up to five machines through an Ubuntu Pro account. Production fleets and any use beyond five machines require a paid Ubuntu Pro subscription, which is priced per-node and includes ESM and the Livepatch service together.

Does kernel live patching require a reboot?

No, that's the whole point. A live patch is loaded as a kernel module that redirects vulnerable functions to fixed replacements while the kernel keeps running. You should still schedule regular rolling reboots (every 60 to 90 days is common) to consolidate accumulated patches and pick up firmware or microcode fixes that live patching cannot deliver.

What is the difference between kpatch and Ubuntu Livepatch?

kpatch is the upstream open-source toolchain (kpatch-build, kpatch) that lets you compile and load your own live patches on any distro. Ubuntu Livepatch is Canonical's managed service that builds, signs, and pushes patches to Ubuntu LTS hosts via the canonical-livepatch daemon. Ubuntu Livepatch internally uses the same in-kernel klp mechanism as kpatch, so you're really paying for the patch content and SLA, not a different technology.

How long does live patching take to apply?

Loading a patch module is instantaneous, but the consistency-model transition (where every task's stack is checked to make sure no thread is still executing the old code) typically completes in a few seconds to a minute. Long-running kernel workqueues can occasionally take longer; watch /sys/kernel/livepatch/<patch>/transition for the drain to complete.

Can you live patch any Linux kernel?

Only kernels built with CONFIG_LIVEPATCH=y, which is enabled by default in most enterprise and mainstream distro kernels on x86_64, arm64, ppc64le, and s390x. Custom-built kernels, some embedded builds, and hardened kernels that disable ftrace cannot be live patched. Check with grep CONFIG_LIVEPATCH /boot/config-$(uname -r).

What is TuxCare KernelCare?

KernelCare is TuxCare's commercial kernel live-patching service. It supports the widest range of distributions in 2026 (Ubuntu, Debian, RHEL, AlmaLinux, Rocky, CloudLinux, Oracle Linux, and Amazon Linux) and offers an on-prem patch relay (ePortal) for air-gapped environments. It's the usual answer for mixed-distro fleets that outgrow Ubuntu Livepatch.