Live kernel patching or reboot: which one VPS need?

What live kernel patching dey do for one VPS

Live kernel patching dey apply kernel security fixes to machine wey dey run, without reboot and without dropping connections. E load fixed copy of one function as kernel module, then redirect every call to the old function go the new copy while the server still dey serve traffic. This one mechanism explain wetin live patching good for and wetin e no fit do.

E dey buy time. E no replace reboot. Server wey dem don live patch for six months still boot from the old kernel image wey dey disk, and every one of those patches dey only for memory.

Dem often dey sell live patching as feature for managed plan. For unmanaged box, you fit enable am yourself with two commands. You suppose know this before you pay for the difference between managed and unmanaged VPS.

How live kernel patching dey work?

Kernel get live patching core wey dem compile inside am with CONFIG_LIVEPATCH. Check your running kernel to confirm say e get am:

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

Line wey show CONFIG_LIVEPATCH=y mean say the kernel wey you dey run build with the core inside. If e no dey there, no live patching service fit do anything for that machine.

The redirection itself dey use ftrace, wey be the kernel function tracer. Dem compile most kernel functions with a call instruction for the very top of the function, before dem touch the arguments or the stack. Ftrace dey use that call site as hook. When dem apply patch, live patching core register ftrace handler for the target function, and the handler send execution go the replacement function instead. Kernel documentation explain am 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 things follow from that sentence, and both go matter later. Only function wey ftrace fit hook dey patchable, so function wey dem compile without that entry call no fit patch at all. And the unit of patching na the whole function, never be one line inside am.

The harder part na how to switch live system safely. If old code still dey run for some CPU stack when you swap the function, you go get mixture of old and new behaviour. Upstream Linux handle this with per-task consistency model. Kernel docs describe am as hybrid: "it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching." Tasks move go the new code one by one, only when kernel fit show say that task no dey inside patched function at that time. Until every task don move, the patch dey transition.

You fit see the result by yourself. Applied patches dey show under /sys/kernel/livepatch, one directory for each patch, with the patched functions listed inside.

ls /sys/kernel/livepatch/

Empty listing mean say no live patch dey loaded for memory. For fresh server, na the normal starting state.

Wetin live kernel patching no fit fix

Na function bodies dey get patch. Everything else no dey.

• Data structures wey change. If upstream fix add field to struct or change wetin existing field mean, no safe way dey to rewrite objects wey dem don allocate and dey use. kpatch project talk the equivalent case directly: "Patches which modify statically allocated data are not directly supported." Shadow variables and callbacks dey as workaround, but na hand-written one for each patch; dem no automatic.
• Fixes wey spread across several functions at once. If fix change lock ordering across group of functions, all of dem need change together. The consistency model switch tasks instead of freezing the whole machine for one exact moment.
• Initialisation code. Functions wey get mark __init don already run and get freed before your server come up, so nothing remain to redirect.
• New kernel versions and new features. Live patching dey move you between patch levels inside one kernel series. E no ever move you from one series go another, and e no ever add feature. If you want something from newer series, like the changes wey land for Linux 7.1, install that kernel and boot am.
• Userspace. Canonical state 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." Kernel wey live patch don fix, but stale OpenSSL still dey beside am, no be patched server. So make unattended upgrades dey handle the userspace packages for the same box.

Ubuntu service get severity boundary too. Canonical talk say e "patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings." CVE (common vulnerabilities and exposures) identifier na name for one flaw, while CVSS na the score wey attach to am. Medium-rated kernel CVE dey get fix for package wey dey disk, but dem no live patch am. So e go reach your running kernel for next reboot, and no be before then.

Wetin be the options for live kernel patching?

Three main lineages dey common use, and all of dem dey use the same kernel machinery.

Canonical Livepatch dey come through Ubuntu Pro. Ubuntu Pro free for personal use, and Canonical talk say e "is and always will be free for personal use on up to 5 physical machines", and e fit reach 50 machines for official Ubuntu Community members. This na the documented limit as of August 2026. Commercial use need paid subscription. Coverage dey granted per kernel series and per flavour. E cover the general availability (GA) kernels for supported long term support (LTS) releases, plus their hardware enablement (HWE) kernels, across flavours like generic, aws, azure, gcp, oracle, ibm and lowlatency. Check your own kernel against Canonical's published kernel list before you depend on am.

KernelCare, from TuxCare, na commercial agent wey cover many distributions, including ones wey no get first-party service. The documented installation na vendor script, curl -s -L https://kernelcare.com/installer | bash, followed by /usr/bin/kcarectl --register KEY for key-based licence. The agent dey check for new patches based on its own schedule, while /usr/bin/kcarectl --update dey force one check. Read the installer before you pipe am go shell for server wey matter to you.

kpatch and kGraft na the ancestors. SUSE bring kGraft, while Red Hat bring kpatch. The live patching core for upstream Linux today na combination of both ideas. kpatch itself dey wind down: its README talk say from Linux 6.19, "the kpatch project is deprecated and in maintenance mode", while kpatch-build dey replaced by klp-build for the upstream kernel. For RHEL and its rebuilds, use the distribution's own service instead of building patches by hand.

Choose based on wetin your distribution support and wetin your licence allow. The result for kernel level dey the same for each option.

How to enable Canonical Livepatch for Ubuntu

First get token from your Ubuntu Pro account page. Both commands below need working outbound network access, because the client dey talk to Canonical servers to attach and fetch patches.

sudo pro attach TOKEN
sudo pro status

If you run sudo pro attach without token, e go start browser-based flow instead and print code wey you go enter for Canonical site. Attaching dey automatically enable the recommended services. For current LTS release, this one includes Livepatch. Use sudo pro attach --no-auto-enable if you prefer choose the services by yourself.

If Livepatch never turn on:

sudo pro enable livepatch
sudo canonical-livepatch status

The service dey run from canonical-livepatch snap, so snapd must dey work before the enable step fit finish. pro status go print table of services with their entitlement and status. canonical-livepatch status go print the detail for each kernel. Canonical documentation show output for 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 get the answer. kernel state show whether the series wey you dey run dey covered by the service at all. This na the line wey go show problem when you boot kernel wey Livepatch no support. patch state show whether the patches wey apply to that kernel don actually load. If kernel dey covered but no patches apply, na client problem. If kernel no dey covered, na kernel problem, and no client setting fit fix am.

How I fit know say reboot dey pending?

Live patching remove the emergency, so pending reboot no dey obvious again. You need check am.

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

The package manager dey create /var/run/reboot-required when an installed package need restart before e fit take effect, and any new linux-image package always dey create am. The .pkgs file dey list the packages wey request am. If the first command answer No such file or directory, no package don request reboot since the machine last boot. For current Ubuntu /var/run na symlink to /run, so either path go reach the same file.

That flag dey inside tmpfs and e reset for every boot, so confirm am against the kernel itself:

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

uname -r dey print the kernel wey you dey run. The second command dey print the kernel packages wey dey installed for disk. If one linux-image for that list newer pass wetin uname -r report, the machine dey run old kernel, no matter wetin Livepatch status talk. Na this check matter, because live patching dey designed to make the running kernel safe, not to make am current.

For the userspace side of the same question, needrestart dey installed by default for Ubuntu Server and e dey list the running services wey still dey hold deleted library files.

sudo needrestart -r l

The -r l flag pair mean "list only", so e go report but e no go change anything.

Wetin make reboot never disappear

The kernel wey dey disk no change. Live patches load enter the kernel wey dey run, and dem no ever write dem into the boot image. So, when you reboot, system go start with any linux-image wey bootloader pick. After that, Livepatch client go apply again the patches wey still apply. Between those two moments, unpatched code dey run. Na another reason to boot current kernel instead of old one.

Coverage dey depend on kernel series, and series dey retire. When the series wey dey run fall off the supported list, the kernel state line stop to report coverage. The only fix na newer kernel. That one mean reboot. For LTS release, the newer series normally reach you as hardware enablement kernel wey dem roll into point release like 26.04.1. So, the replacement don already dey for the archive. The only thing wey remain na to schedule a boot.

Dem no ever live patch medium and low severity kernel fixes. Dem dey inside the package for disk, and dem reach you only when you boot.

Kernels wey run for long time also dey collect state wey patching no clean. Canonical own position worth quoting, because e honest: Livepatch "no be replacement for rebooting. Na tool wey give you more control by preventing unscheduled reboots." The word wey carry the meaning na unscheduled. You still reboot. Na you choose when.

How to schedule reboot wey go come back up

VPS reboot na one-way matter if you no fit reach console. Before you type reboot, make sure say you fit enter again if the machine no return.

• Confirm say your provider dey give you serial console or VNC (virtual network computing) view for control panel, and open am now instead of waiting until outage happen.
• Check free space with df -h /boot. If /boot full, kernel package fit fail while e dey write initramfs (initial RAM filesystem). This fit leave bootloader entry wey dey point to image wey never finish.
• Keep at least one known-good older kernel installed. GRUB dey list am under "Advanced options for Ubuntu", and booting am na the fastest recovery when new kernel fail.
• Find your provider rescue mode before you need am. If console show initramfs prompt after reboot, na there you go do the repair.

Then reboot for time wey you go dey awake:

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

This one schedule reboot for five minutes later and send message to logged-in users. sudo shutdown -c cancel am. When machine return, confirm both parts:

uname -r
sudo canonical-livepatch status

uname -r suppose report the newer kernel now, and status output suppose report say the new series dey covered. If machine no come back at all, the fault almost always dey for boot path, not network, and recovery route na the one for guide about VPS wey no go boot after kernel update.

Why e still important to clean old kernels comot

Live patching make this problem worse instead of better, because e remove the pressure to reboot while linux-image packages dey continue to install. Every kernel dey install a boot image, an initramfs, a modules tree, and usually a headers package. For small VPS wey get separate /boot partition of few hundred megabytes, three or four of dem fit fill am.

Full /boot go then stop the next kernel installation, and na so machine fit end up unable to receive the exact update wey e need. The apt autoremove path dey clear old kernels once dem qualify, but for machine wey never reboot, dem no always qualify yet, because package manager no go retire kernel wey you fit still dey run.

So check wetin dey installed, keep the running kernel and one known-good fallback, then remove the rest with this safe procedure to remove old kernels for Ubuntu. Never remove the kernel wey uname -r dey report as currently running.

FAQ

Live kernel patching mean say I no ever need reboot my VPS?

No. Live patches dey load inside the kernel wey dey run, and dem no dey write am into the boot image. So the linux-image for disk remain for the version wey you boot before. Canonical talk am directly: Livepatch "is not a replacement for rebooting. It is a tool that gives you more control by preventing unscheduled reboots." Coverage too go end when dem retire your kernel series, and dem no dey live patch medium severity kernel fixes at all. Schedule maintenance reboot according to timetable wey you choose, instead make you wait until dem force am.

How I fit check whether live kernel patching dey really apply patches?

Run sudo canonical-livepatch status and read two lines. kernel state show whether the service cover your running kernel series, while patch state show whether the patches for that kernel don load. You fit also check the kernel side directly with ls /sys/kernel/livepatch/. E list one directory for every patch wey don load. If the listing empty, nothing dey patched for memory now, no matter wetin the client talk.

Ubuntu Pro free for personal VPS?

Yes, but e get documented limit. Canonical talk say Ubuntu Pro "is and always will be free for personal use on up to 5 physical machines", and the limit rise to 50 machines for official Ubuntu Community members, as of August 2026. Commercial use need paid subscription. You attach machine with sudo pro attach TOKEN, using token from your Ubuntu Pro account page. Then enable the service with sudo pro enable livepatch.

Why kernel CVE still dey show as unfixed after Livepatch run?

Usually, na one of two reasons. The fix fit dey 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 remaining fixes for the package wey dey on disk. Or the fix fit no be something wey you fit express as change to function body. For example, upstream fit don change a data structure, and live patching no fit safely do that to objects wey don already allocate. Both cases get the same solution: install the updated kernel package and boot into am.

Wetin live kernel patching no cover at all?

Userspace. Canonical make am clear say Livepatch "does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." E no fit deliver new kernel version or new feature too, because e only replace function bodies inside the series wey you dey run already. And e no fit patch __init functions, because dem don already run and get freed from memory before the server come up.