Kernel Live Patching with kpatch: Applying Security Updates Without a Reboot

1. Why patch without a reboot at all?

A kernel security update traditionally only takes effect after a reboot, since the running kernel in memory stays unchanged until the system restarts and loads the updated kernel. For a single web server behind a load balancer, that is usually not a big deal, but for a heavily loaded database primary, a stateful cache cluster node, or a server running very long cron jobs, a reboot costs real time and creates real coordination overhead.

Kernel live patching addresses exactly this: a critical security fix gets applied to the already running kernel at runtime, without losing process memory or dropping active network connections. The actual reboot that brings new features, larger structural changes, or a new major kernel version is still due on a regular basis, and live patching only makes it schedulable rather than replacing it entirely.

2. How kpatch works technically

kpatch builds on the same ftrace mechanism also used for kernel tracing: at the entry point of a patched function, a jump instruction gets inserted that redirects the call to the new, corrected function version, while the original function code stays unchanged in memory. This technique is called function redirection and works because the kernel already carries a mechanism for ftrace instrumentation on nearly every function.

The actual patch is not written by hand, but generated by kpatch-build from two versions of the kernel source code: the original and the patched variant. The tool compiles both versions, compares the resulting object files, and automatically extracts only the functions that actually changed into a loadable kernel module.

# Build a kpatch kernel module from a source patch (simplified example)
kpatch-build -t vmlinux \
  --sourcedir /usr/src/kernels/$(uname -r) \
  cve-2026-xxxxx.patch

# Result: a loadable kernel module
ls kpatch-*.ko

3. The kpatch toolchain in day to day use

In day to day operation, the routine work usually boils down to three commands: kpatch load loads an already built patch module into the running kernel, kpatch list shows every currently active patch along with the functions it touches, and kpatch unload removes a patch again, provided no other dependency blocks it.

For persistence across a reboot, the systemd service kpatch.service automatically reloads every patch stored under /var/lib/kpatch at system startup. Without this step, every live patch would disappear after a regular reboot, since a freshly started kernel naturally starts out in its unpatched state again.

# Load a patch module and register it permanently for future boots
sudo kpatch install kpatch-cve-2026-xxxxx.ko
sudo kpatch load /var/lib/kpatch/$(uname -r)/kpatch-cve-2026-xxxxx.ko

# List active patches and the functions they affect
sudo kpatch list

# Remove a patch again if needed
sudo kpatch unload kpatch-cve-2026-xxxxx

4. Canonical Livepatch for Ubuntu servers

Canonical offers Ubuntu LTS servers its own cloud backed service called Livepatch, which automatically fetches prebuilt patches through an Ubuntu Advantage or Ubuntu Pro subscription and applies them in the background, without administrators having to build a patch themselves with kpatch-build. The service remains usable for a limited number of machines even without a paid subscription.

Activation happens through the canonical-livepatch command line tool, which needs a one time activation token from an Ubuntu One account and then autonomously downloads new patches as soon as Canonical releases them for the installed kernel version.

# Install the Livepatch client and enable it with a token
sudo snap install canonical-livepatch
sudo canonical-livepatch enable <TOKEN>

# Show status and the patches currently applied
sudo canonical-livepatch status --verbose

5. Red Hat kpatch and SUSE kGraft compared

Red Hat integrates kpatch directly into RHEL and offers prebuilt patches for selected, security relevant CVEs through the Red Hat Kernel Livepatch Service, installable through the regular package manager as a kpatch-patch package once a Red Hat subscription with the right entitlement is in place. The service deliberately covers only a subset of all CVEs, prioritized by actual exploitation risk.

SUSE takes a technically related but independently implemented approach with kGraft, which also relies on function redirection but uses its own consistency model to cleanly synchronize the transition between the old and new function while calls to the affected function are still in flight.

# RHEL: list available kpatch patches for the running kernel
sudo yum list available 'kpatch-patch*'

# Install a specific patch package
sudo yum install kpatch-patch-5_14_0-570

# Check the active patch status
sudo kpatch list

6. Limits: not every CVE can be live patched

Live patching works reliably for locally scoped function fixes, such as a faulty bounds check in a network driver. But once a security fix reaches deep into data structures, for example requiring a new structure size or changed locking behavior that would collide with already running instances still in the old format, the patch cannot be safely implemented as a pure function redirect.

In such cases, kpatch-build marks the build as failed, or the patch vendor simply does not ship a live patch for that CVE at all and points explicitly to a regular kernel reboot instead. Live patching is therefore a complement to regular patch management, not a full replacement, and a reboot window should never disappear entirely from the schedule just because a live patching program is in place.

7. Monitoring and verifying active patches

In a mixed server landscape with many machines, it is worth centrally tracking which live patch level is active on which host, since kpatch list only reports locally. A simple monitoring script that reads the status regularly and reports it to a central monitoring system prevents individual servers from silently falling behind the expected patch level.

Beyond a simple status check, it is worth cross referencing the running kernel version from uname against the list of known, still open CVEs, since kpatch list shows which patches are loaded, but does not automatically confirm that every relevant security issue for that kernel version has actually been closed.

# Simple check for monitoring systems: number of active patches
kpatch list | grep -c '\[enabled\]'

# Capture kernel version and patch level together
echo "kernel=$(uname -r) patches=$(kpatch list | grep -c enabled)"

8. Integration into the regular patch management process

Live patching should be understood as an additional, faster response layer for critical CVEs, not a replacement for the regular maintenance cycle. A sensible process reacts to a freshly published critical CVE with a live patch first, if one is available, and still schedules the full kernel reboot with the regular update for the next planned maintenance window.

Documenting which live patches are active on which server also matters, because a later regular reboot with the full kernel update makes the live patch obsolete and automatically supersedes it. Without clean tracking, uncertainty creeps in about whether a server actually ends up at the same security level after a reboot that it previously reached through live patching alone.

9. Practical example: use in a Magento hosting context

On a MySQL primary serving a Magento cluster with several frontend nodes, or a Redis node holding session and cache data for many concurrent checkout flows, an unplanned reboot outside a maintenance window is especially costly, since failover mechanisms can cause brief interruptions even with a clean design. Live patching allows reacting to a critical kernel CVE within minutes without taking on that risk.

For stateless web servers behind a load balancer, the extra effort for live patching pays off less often, since a rolling reboot of individual nodes is usually possible without noticeable downtime anyway. The biggest payoff from live patching therefore sits specifically with the few, genuinely critical servers in the infrastructure that are hard to make redundant.

10. Summary

11. FAQ: Kernel Live Patching