Kernel live patching: Livepatch, kpatch, SUSE KLP, Ksplice, KernelCare

Updated November 2026

Kernel live patching loads a fix for a serious kernel vulnerability into the running kernel, so the hole is closed without a reboot. It buys time. It does not replace kernel updates, and it does not remove the need to reboot on a regular schedule.

How it works

A live patch is a kernel module that contains new versions of the functions that had the bug. When it loads, the kernel redirects calls from the old functions to the new ones, using the same tracing mechanism (ftrace) that debugging tools use. Each running task is switched to the new code when it is safe to do so. Once every task has switched, the fix is in force.

Upstream Linux has had this mechanism for years; each vendor builds and tests the patch modules for its own kernels and delivers them through its own service. You can see loaded patches on any distribution:

ls /sys/kernel/livepatch/
cat /sys/kernel/livepatch/*/enabled    # 1 = active

What it does not cover

Only selected fixes. Vendors ship live patches for high and critical vulnerabilities. Lower-priority CVEs, ordinary bug fixes, driver updates, performance changes and new features come only with a full kernel update and reboot.
Not every serious fix. Some fixes change how data is laid out in memory or touch code that cannot be traced, so they cannot be applied to a running kernel. Red Hat states plainly that live patching does not address all critical or important CVEs.
Only the kernel. Libraries such as glibc and OpenSSL, services, CPU microcode and firmware are not covered by kernel live patches. Two commercial services, Oracle Ksplice and TuxCare, offer separate user-space patching for some libraries.
Only for a limited time per kernel. Every service stops producing patches for a given kernel build after a set period. After that you must install a newer kernel and reboot.
Only supported kernels. Custom-built kernels and kernels outside the vendor's live patch cadence get nothing.

The options compared

Kernel live patching services, as of November 2026
Service	Systems	Who can use it	Status command
Canonical Livepatch	Ubuntu	Ubuntu Pro; free for up to 5 machines for personal use	`canonical-livepatch status`
kpatch	Red Hat Enterprise Linux	RHEL subscription	`kpatch list`
SUSE Linux Enterprise Live Patching	SUSE Linux Enterprise Server	Live Patching extension subscription	`klp status`
Oracle Ksplice	Oracle Linux	Oracle Linux Premier Support and Oracle Cloud Infrastructure	`ksplice kernel show`
TuxCare KernelCare	Several distributions	Commercial subscription	`kcarectl --info`

Ubuntu: Canonical Livepatch

Livepatch is part of Ubuntu Pro and targets high and critical kernel vulnerabilities. Attach the machine to your Pro subscription, then enable it:

sudo pro attach YOUR_TOKEN
sudo pro enable livepatch
canonical-livepatch status --verbose

The status output has two parts. The kernel line tells you whether your running kernel is covered and until what date, with a reminder to install available kernel updates and reboot before then. The patch line should read "all applicable live kernel patch modules applied". A line starting with ✗, such as "kernel is not covered by Livepatch" or "Livepatch coverage ended", means you need a kernel update and a reboot now. The client checks for new patches every hour.

RHEL: kpatch

Red Hat ships live patches as kpatch-patch packages, one per kernel build, each containing the cumulative fixes for that kernel.

# install the live patch for the running kernel
sudo dnf install "kpatch-patch = $(uname -r)"

# subscribe all installed kernels to future live patches
sudo dnf install kpatch-dnf
sudo dnf kpatch auto

# check what is loaded
sudo kpatch list
rpm -qa | grep kpatch

Not every kernel receives live patches. With a standard subscription, live patches for a minor release stop once the next minor release ships (for example, the RHEL 9.1 kernel stops getting them when 9.2 is out), so keep moving to current kernels. Red Hat warns not to use SystemTap or kprobes during or after loading a patch, and it does not support live patches from third parties.

SUSE: Kernel Live Patching

On SUSE Linux Enterprise Server 15 SP7, register the Live Patching extension and install the pattern:

sudo SUSEConnect --list-extensions
sudo SUSEConnect -p sle-module-live-patching/15.7/x86_64 -r REGISTRATION_CODE
sudo zypper install -t pattern lp_sles

# check status and list patches with the CVEs they fix
sudo klp status
sudo klp -v patches
zypper lifecycle

SUSE produces live patches for fixes rated CVSS 7 or higher and for serious stability or data-corruption bugs. Each kernel gets live patches for 13 months from its release; zypper lifecycle (with the lifecycle-data-sle-module-live-patching package) shows the end dates. The active live patch is included in the initrd, so an unplanned reboot comes back up with the fixes applied.

Oracle Linux: Ksplice

Ksplice is free for Oracle Linux Premier Support customers and on Oracle Cloud Infrastructure. It patches the kernel and, with the Enhanced client, user-space libraries such as glibc and OpenSSL in running processes. Oracle says it covers Critical, Important and selected Moderate CVEs.

sudo ksplice kernel show                # updates applied to the running kernel
sudo ksplice kernel show --available    # updates not yet applied
sudo ksplice all show                   # kernel and user space
sudo ksplice kernel uname -r            # effective kernel version

TuxCare KernelCare

KernelCare is a commercial service from TuxCare that is not tied to one distribution vendor. It checks for new patches every 4 hours. Its LibCare component patches glibc and OpenSSL in memory on x86-64. Check the current list of supported kernels on TuxCare's site before you buy, and note that Red Hat does not support third-party live patches on RHEL.

sudo kcarectl --info        # patches installed
sudo kcarectl --uname       # effective ("safe") kernel version
sudo kcarectl --patch-info  # list applied patches

Scanners and uname

Live patches do not change the output of uname -r. A vulnerability scanner that compares the kernel version with an advisory will still report the CVE as open. Use the vendor tool to prove the fix is loaded: ksplice kernel uname -r, kcarectl --uname, klp -v patches, kpatch list or the Livepatch status, and record that in your scan exceptions.

Still reboot regularly

Canonical puts it simply: Livepatch is not a replacement for rebooting. Use live patching to close the worst holes the day they are announced, then install the full kernel update and reboot in your next maintenance window, for example once a month. That way you also get the lower-priority fixes, you stay inside the vendor's patch window, and you confirm that the server still boots cleanly.

Plan the reboot with Kernel updates and clear up services that still use old libraries with Restarts and reboots.