A kernel security fix normally means a reboot. On a fleet, that means a maintenance window and coordination. Live patching applies some fixes to the running kernel.

The mechanism

It rests on ftrace, the kernel’s function tracing infrastructure.

Most kernel functions are compiled with a small no-op placeholder at their entry point. ftrace can replace that with a jump, which is how tracing attaches to arbitrary functions.

Live patching uses the same hook for a different purpose. A patch module contains a fixed version of the function, and applying it redirects the entry point so calls land on the new code instead of the old.

call vulnerable_function()
    -> ftrace hook at function entry
    -> redirect to patched_vulnerable_function()

The interesting problem is consistency: what about threads already executing inside the old function, or with it on their stack?

The kernel solves this with a per-task transition. Each task is checked, and switched to the new code only when it is not executing any patched function. Tasks in the old code finish there; new calls go to the new version. Once every task has transitioned, the patch is fully applied.

That is why applying a patch is not instantaneous and why a task blocked for a long time in a patched function can stall the transition.

What it cannot do

This is the part people underestimate.

Data structure changes. If the fix adds a field to a struct, every existing instance in memory has the old layout. You cannot rewrite them all safely.

Changes to initialisation. Code that runs once at boot has already run.

Semantics spanning many call sites. A fix changing how a subsystem behaves across dozens of functions is not a function-level replacement.

Changes to inlined functions. If the compiler inlined the vulnerable code into its callers, there is no single entry point to redirect. The patch must then replace every caller, which may or may not be tractable.

The practical result is that a meaningful fraction of kernel security fixes cannot be live patched. Vendors publish which CVEs are covered, and the list is never all of them.

Using it

Ubuntu

sudo snap install canonical-livepatch
sudo canonical-livepatch enable <token>
canonical-livepatch status --verbose

Free for a small number of machines on a personal account, paid through Ubuntu Pro beyond that.

RHEL

sudo dnf install kpatch
sudo kpatch list
sudo kpatch install kpatch-5_14_0-x86_64.ko

Included with a subscription.

SUSE

sudo zypper install kernel-livepatch
sudo klp status

Checking

ls /sys/kernel/livepatch/
cat /sys/kernel/livepatch/*/enabled
cat /sys/kernel/livepatch/*/transition

uname -r still reports the original kernel version. This catches people out: a vulnerability scanner checking kernel version flags a patched machine as vulnerable, because the version string does not change. That is a false positive and it generates a lot of unnecessary work if nobody knows why.

Why it does not remove reboots

Worth being clear, because it is sometimes sold as though it does.

Patches accumulate. Each one adds redirections. Vendors cap how many apply before requiring a reboot, and the stack of grafted functions is not something anyone wants growing indefinitely.

Some fixes are not patchable. Those still need the reboot.

You are running an old kernel. Live patching fixes specific known issues. It does not give you new hardware support, new features, or the thousands of other fixes in a newer release. Our stable kernel coverage notes that a point release carries over 550 patches, and live patching delivers a handful of them.

Drift. A fleet where machines have been live patched for months has kernels in states no vendor tested as a combination.

The honest framing: live patching buys scheduling flexibility. You patch a critical CVE immediately and reboot during a planned window rather than at 2am. That is genuinely valuable and it is not the same as eliminating reboots.

Where it fits

Worth it: servers with real uptime requirements, fleets where coordinating reboots is expensive, and anything under a compliance regime with a short patching deadline.

Not worth it: desktops and laptops, which reboot regularly anyway. Machines you can reboot freely. Anything where the subscription cost exceeds the inconvenience it removes.

For most self-hosted setups, scheduling a monthly reboot is simpler than a live patching subscription. Our cron versus timers guide covers automating the update side, and needrestart will tell you when a reboot is actually required:

sudo apt install needrestart
sudo needrestart -r l
ls /var/run/reboot-required 2>/dev/null && echo "reboot needed"

The userspace half

Worth knowing, because the kernel is not the only thing needing a restart after an update.

sudo needrestart

A library update means every process that loaded the old version is still running it. Our static and dynamic linking guide covers why: the mapping happened at process start and does not change underneath a running process.

So patching OpenSSL and not restarting the services using it leaves them vulnerable, with no indication anything is wrong. That is a considerably more common oversight than an unpatched kernel, and it costs nothing to check.

Frequently Asked Questions

How does kernel live patching work?

It loads a module containing fixed versions of functions and uses the ftrace infrastructure to redirect calls from the old function to the new one. Existing callers finish under the old code and subsequent calls go to the patched version, so the fix takes effect without restarting.

Can live patching fix every kernel vulnerability?

No. It handles fixes contained within function bodies. Changes to data structures, to how memory is laid out, or that alter semantics across many call sites cannot be applied this way, so a meaningful fraction of security fixes still require a reboot.

Does live patching mean I never have to reboot?

No, it delays reboots rather than removing them. Patches accumulate, some fixes cannot be live patched at all, and you are still running an old kernel with new function bodies grafted on. Treat it as scheduling flexibility, not as permission to run a kernel for years.

What is the difference between kpatch, kGraft, and livepatch?

kpatch came from Red Hat and kGraft from SUSE, solving the same problem differently. The upstream kernel merged a common infrastructure called livepatch that both now build on, so the differences today are mostly in tooling and distribution rather than mechanism.

Is live patching free?

The kernel infrastructure is in mainline and free. The patches themselves are a service, because producing and testing them for every kernel version is ongoing work. Canonical, Red Hat, SUSE, and Oracle all charge for it, with Ubuntu offering free personal tiers for a small number of machines.

Can I tell whether a live patch is applied?

Yes. The sysfs tree under /sys/kernel/livepatch lists loaded patches and which functions they affect, and the service tools report status. Note that uname still reports the original kernel version, which is why version-based vulnerability scanners produce false positives on live patched systems.