Live kernel patching vs rebooting your VPS

What live kernel patching does on a VPS

Live kernel patching applies kernel security fixes to a running machine, with no reboot and no dropped connections. A fixed copy of a function is loaded as a kernel module, and every call to the old function is redirected to the new copy while the box keeps serving traffic. That one mechanism explains both what live patching is good at and what it cannot do.

It buys time. It does not retire the reboot. A server that has been live patched for six months is still booted on the old kernel image on disk, and every one of those patches lives only in memory.

Live patching is often sold as a feature of a managed plan. On an unmanaged box you enable it yourself with two commands, which is worth knowing before you pay for the difference between a managed and an unmanaged VPS.

How does live kernel patching work?

The kernel has a built-in live patching core, compiled in with CONFIG_LIVEPATCH. Check your running kernel for it:

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

A line reading CONFIG_LIVEPATCH=y means the kernel you are running was built with the core present. Without it, no live patching service can do anything on that machine.

The redirection itself uses ftrace, the kernel's function tracer. Most kernel functions are compiled with a call instruction at the very top of the function, before the arguments or the stack have been touched. Ftrace uses that call site as a hook. When a patch is applied, the live patching core registers an ftrace handler on the target function, and the handler sends execution to the replacement function instead. The kernel documentation puts it plainly: "Livepatching typically needs to redirect the code at the very beginning of the function entry before the function parameters or the stack are in any way modified."

Two consequences follow from that sentence, and both matter later. Only a function ftrace can hook is patchable, so a function compiled without that entry call cannot be patched at all. And the unit of patching is a whole function, never a single line inside one.

The harder part is switching a live system safely. If old code is still running on some CPU's stack when you swap the function, you get a mix of old and new behaviour. Upstream Linux handles this with a per-task consistency model, described in the kernel docs as a hybrid: "it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching." Tasks move to the new code one at a time, only when the kernel can show that task is not currently inside a patched function. Until every task has moved, the patch is in transition.

You can see the result yourself. Applied patches appear under /sys/kernel/livepatch, one directory per patch, with the patched functions listed inside.

ls /sys/kernel/livepatch/

An empty listing means no live patch is loaded in memory, which on a fresh server is the normal starting state.

What live kernel patching cannot fix

Function bodies get patched. Everything else does not.

• Changed data structures. If the upstream fix adds a field to a struct or changes what an existing field means, there is no safe way to rewrite objects that are already allocated and in use. The kpatch project states the equivalent case directly: "Patches which modify statically allocated data are not directly supported." Shadow variables and callbacks exist as a workaround, but they are hand-written per patch, not automatic.
• Fixes spread across several functions at once. A fix that changes lock ordering across a group of functions needs all of them to change together, and the consistency model switches tasks rather than freezing the whole machine at a single instant.
• Initialisation code. Functions marked __init have already run and been freed by the time your server is up, so there is nothing left to redirect.
• New kernel versions and new features. Live patching moves you along a patch level inside one kernel series. It never moves you from one series to the next, and it never adds a feature. If you want something from a newer series, such as the changes that landed in Linux 7.1, you install that kernel and you boot it.
• Userspace. Canonical states the boundary itself: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." A live patched kernel next to a stale OpenSSL is not a patched server, so keep unattended upgrades handling the userspace packages on the same box.

There is also a severity boundary on Ubuntu's service. Canonical says it "patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings." A CVE (common vulnerabilities and exposures) identifier names one flaw, and CVSS is the score attached to it. A medium-rated kernel CVE is fixed in the package on disk and is not live patched, so it reaches your running kernel at the next reboot and not before.

What are the live kernel patching options?

There are three lineages in common use, and they all drive the same kernel machinery.

Canonical Livepatch is delivered through Ubuntu Pro. Ubuntu Pro is free for personal use, and Canonical's wording is that it "is and always will be free for personal use on up to 5 physical machines", rising to 50 machines for official Ubuntu Community members. That is the documented limit as of August 2026. Commercial use needs a paid subscription. Coverage is granted per kernel series and per flavour, covering the general availability (GA) kernels of the supported long term support (LTS) releases plus their hardware enablement (HWE) kernels, across flavours such as generic, aws, azure, gcp, oracle, ibm and lowlatency. Check your own kernel against Canonical's published kernel list before you rely on it.

KernelCare, from TuxCare, is a commercial agent that covers many distributions, including ones with no first-party service. Its documented install is a vendor script, curl -s -L https://kernelcare.com/installer | bash, followed by /usr/bin/kcarectl --register KEY for a key-based licence. The agent then checks for new patches on its own schedule, and /usr/bin/kcarectl --update forces a check. Read the installer before you pipe it to a shell on a server you care about.

kpatch and kGraft are the ancestors. kGraft came from SUSE, kpatch from Red Hat, and the live patching core in upstream Linux today is the merge of both ideas. kpatch itself is winding down: its README states that from Linux 6.19 "the kpatch project is deprecated and in maintenance mode", with kpatch-build being replaced by klp-build in the upstream kernel. On RHEL and its rebuilds, the tool you want is the distribution's own service rather than building patches by hand.

Choose on what your distribution supports and what your licence permits. The kernel-level result is the same in each case.

How to enable Canonical Livepatch on Ubuntu

Get a token from your Ubuntu Pro account page first. Both commands below need working outbound network access, because the client talks to Canonical's servers to attach and to fetch patches.

sudo pro attach TOKEN
sudo pro status

Running sudo pro attach with no token starts a browser-based flow instead and prints a code to enter on Canonical's site. Attaching auto-enables the recommended services, which on a current LTS release includes Livepatch. Use sudo pro attach --no-auto-enable if you would rather pick the services yourself.

If Livepatch is not already on:

sudo pro enable livepatch
sudo canonical-livepatch status

The service runs from the canonical-livepatch snap, so snapd has to be working for the enable step to finish. pro status prints a table of services with their entitlement and status. canonical-livepatch status prints the per-kernel detail, and Canonical's documentation shows output in this shape:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

Two lines carry the answer. kernel state says whether the series you are running is covered by the service at all, and it is the line that turns bad when you boot a kernel Livepatch does not support. patch state says whether the patches that apply to that kernel are actually loaded. A covered kernel with no patches applied is a client problem. An uncovered kernel is a kernel problem, and no client setting fixes it.

How do I tell whether a reboot is pending?

Live patching removes the emergency, so a pending reboot stops being obvious. You have to look for it.

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

The package manager creates /var/run/reboot-required when an installed package needs a restart to take effect, and a new linux-image package always creates it. The .pkgs file lists which packages asked. If the first command answers No such file or directory, nothing has requested a reboot since the machine last booted. On current Ubuntu /var/run is a symlink to /run, so either path reaches the same file.

That flag lives in a tmpfs and resets at every boot, so confirm it against the kernel itself:

uname -r
dpkg -l 'linux-image-*' | grep ^ii

uname -r prints the kernel you are running. The second command prints the kernel packages installed on disk. A linux-image in that list newer than what uname -r reports means the machine is running an old kernel, whatever the Livepatch status says. This is the check that matters, because live patching is built to make the running kernel safe, not to make it current.

For the userspace half of the same question, needrestart is installed by default on Ubuntu Server and lists the running services still holding deleted library files.

sudo needrestart -r l

The -r l flag pair means "list only", so it reports and changes nothing.

Why the reboot never goes away

The kernel on disk is unchanged. Live patches are loaded into the running kernel and are never written into the boot image, so a reboot brings you up on whatever linux-image the bootloader picks, and the Livepatch client then reapplies the patches that still apply. Between those two moments you are running unpatched code, which is one more reason to boot a current kernel rather than an old one.

Coverage is per kernel series, and series get retired. When your running series falls off the supported list, the kernel state line stops reporting coverage, and the only fix is a newer kernel. That is a reboot.

Medium and low severity kernel fixes are never live patched. They sit in the package on disk and reach you only when you boot.

Long-running kernels also accumulate state that patching does not clean. Canonical's own position is worth quoting, because it is the honest one: Livepatch "is not a replacement for rebooting. It is a tool that gives you more control by preventing unscheduled reboots." The word carrying the meaning there is unscheduled. You still reboot. You choose when.

How to schedule a reboot that comes back up

A VPS reboot is one-way if you cannot reach the console. Before you type reboot, make sure you can get back in when the machine does not return.

• Confirm your provider gives you a serial console or VNC (virtual network computing) view in the control panel, and open it now rather than during the outage.
• Check free space with df -h /boot. A full /boot makes the kernel package fail while writing its initramfs (initial RAM filesystem), which can leave a bootloader entry pointing at an image that was never finished.
• Keep at least one known-good older kernel installed. GRUB lists it under "Advanced options for Ubuntu", and booting it is the fastest recovery when a new kernel fails.
• Find your provider's rescue mode before you need it. If the console shows an initramfs prompt after the reboot, that is where the repair happens.

Then reboot at a time you are awake for:

sudo shutdown -r +5 "Kernel update, back in a moment"

That schedules the reboot five minutes out and sends a message to logged-in users. sudo shutdown -c cancels it. When the machine returns, confirm both halves:

uname -r
sudo canonical-livepatch status

uname -r should now report the newer kernel, and the status output should report the new series as covered. If the machine does not come back at all, the fault is almost always in the boot path rather than the network, and the recovery route is the one in the guide to a VPS that will not boot after a kernel update.

Why old kernels still need cleaning out

Live patching makes this problem worse rather than better, because it removes the pressure to reboot while linux-image packages keep installing. Each kernel installs a boot image, an initramfs, a modules tree and usually a headers package. On a small VPS with a separate /boot partition of a few hundred megabytes, three or four of them fill it.

A full /boot then breaks the next kernel install, which is how a machine ends up unable to take the very update it needs. The apt autoremove path clears old kernels once they are eligible, but on a box that never reboots they are not always eligible yet, because the package manager will not retire a kernel you might still be running.

So check what is installed, keep the running kernel and one known-good fallback, and remove the rest using the safe procedure for removing old kernels on Ubuntu. Never remove the kernel uname -r currently reports.

FAQ

Does live kernel patching mean I never have to reboot my VPS?

No. Live patches load into the running kernel and are not written into the boot image, so the linux-image on disk stays at whatever version you booted. Canonical states it directly: Livepatch "is not a replacement for rebooting. It is a tool that gives you more control by preventing unscheduled reboots." Coverage also ends when your kernel series is retired, and medium severity kernel fixes are never live patched at all. Schedule a maintenance reboot on a cadence you choose instead of waiting for one to be forced on you.

How do I check whether live kernel patching is actually applying patches?

Run sudo canonical-livepatch status and read two lines. kernel state reports whether your running kernel series is covered by the service, and patch state reports whether the patches for that kernel are loaded. You can also check the kernel side directly with ls /sys/kernel/livepatch/, which lists one directory per loaded patch. An empty listing means nothing is patched in memory right now, whatever the client says.

Is Ubuntu Pro free on a personal VPS?

Yes, inside a documented limit. Canonical's wording is that Ubuntu Pro "is and always will be free for personal use on up to 5 physical machines", rising to 50 machines for official Ubuntu Community members, as of August 2026. Commercial use needs a paid subscription. You attach a machine with sudo pro attach TOKEN using a token from your Ubuntu Pro account page, then enable the service with sudo pro enable livepatch.

Why is a kernel CVE still listed as unfixed after Livepatch runs?

Usually one of two reasons. The fix may sit below the severity threshold, because Canonical live patches "kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings" and leaves the rest to the package on disk. Or the fix may not be expressible as a change to a function body, for example when upstream altered a data structure, which live patching cannot do safely on objects already allocated. Both cases resolve the same way: install the updated kernel package and boot into it.

What does live kernel patching not cover at all?

Userspace. Canonical is explicit that Livepatch "does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." It also cannot deliver a new kernel version or a new feature, since it only replaces function bodies inside the series you are already running. And it cannot patch __init functions, which have already run and been freed from memory by the time the server is up.