Live Kernel Patching vs Reboot: Which One Better?

Wetin live kernel patching dey do for VPS

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

E dey buy time. E no remove the need for reboot. Server wey dem 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 sell live patching as feature of managed plan. For unmanaged box, you fit enable am yourself with two commands. E good make you know this before you pay for the difference between managed and unmanaged VPS.

Live kernel patching dey work how?

Kernel get built-in live patching core, and dem compile am with CONFIG_LIVEPATCH. Check your running kernel for am:

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

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

The redirection dey use ftrace, wey be kernel function tracer. Dem compile most kernel functions with a call instruction for the very beginning of the function, before dem touch the arguments or 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 talk 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 fit be patched. So, function wey dem compile without that entry call no fit be patched at all. Also, patching unit na the whole function, never just 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 the 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, with one directory for each patch. The patched functions dey listed inside.

ls /sys/kernel/livepatch/

If the listing empty, e 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 patched. Everything else no dey.

• Changed data structures. If upstream fix add field to a struct or change wetin existing field mean, no safe way dey to rewrite objects wey don already 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 work for each patch, no be automatic.
• Fixes wey spread across several functions at once. Fix wey change lock ordering across group of functions need all of dem change together, and the consistency model switch tasks instead of freezing the whole machine for one instant.
• 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 to another, and e no ever add feature. If you want something from newer series, like 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." Live patched kernel beside stale OpenSSL 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." A CVE (common vulnerabilities and exposures) identifier dey name one flaw, and CVSS na the score wey attach to am. Medium-rated kernel CVE dey fixed for package wey dey disk and no dey live patched, so e go reach your running kernel for next reboot, no be before then.

Wetin be di options for live kernel patching?

Three main lineages dey common, 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. Na so the documented limit be 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. This include 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 licence wey use key. After that, the agent dey check for new patches according to its own schedule, and /usr/bin/kcarectl --update go force one check. Read the installer before you pipe am go shell for server wey important to you.

kpatch and kGraft na the ancestors. SUSE create kGraft, while Red Hat create 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 kernel-level result na 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 auto-enable the recommended services. For current LTS release, this one include Livepatch. Use sudo pro attach --no-auto-enable if you prefer choose the services by yourself.

If Livepatch never dey enabled:

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 dey print table of services with their entitlement and status. canonical-livepatch status dey print the detail for each kernel. Canonical documentation show output for this format:

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 dey show whether the series wey you dey run dey covered by the service at all. Na this line go show problem when you boot kernel wey Livepatch no support. patch state dey 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 dey remove the emergency, so pending reboot no dey obvious again. You gats check for am.

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

Package manager dey create /var/run/reboot-required when installed package need restart before e fit take effect, and new linux-image package always dey create am. .pkgs file dey list the packages wey request am. If first command answer No such file or directory, no package don request reboot since 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 every boot, so confirm am against the kernel itself:

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

uname -r go print the kernel wey you dey run. The second command go print the kernel packages wey dey installed for disk. If linux-image for that list newer pass wetin uname -r report, machine dey run old kernel, no matter wetin Livepatch status talk. Na this check matter, because live patching dey make the kernel wey dey run safe, but e no dey 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

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

Why reboot never dey go away

The kernel for disk no change. Live patches load inside the kernel wey dey run, and dem no dey ever write am inside boot image. So when you reboot, system go come up with whichever linux-image bootloader pick, then Livepatch client go apply again the patches wey still fit work. Between those two moments, you dey run code wey no get patches. This na another reason to boot current kernel instead of old one.

Coverage dey apply per kernel series, and dem dey retire series. When the series wey dey run fall off the supported list, the kernel state line go stop to report coverage. The only fix na newer kernel. That one na reboot.

Dem no dey live patch medium and low severity kernel fixes. Dem dey remain inside package for disk, and you go only get dem when you boot.

Kernels wey run for long time also dey gather state wey patching no dey clean. Canonical own position dey 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 dey reboot. Na you dey choose when.

How to schedule reboot wey go come back

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

• Confirm say your provider dey give you serial console or VNC (virtual network computing) view for the 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 im 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's 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 five minutes from now and send message to users wey dey logged in. sudo shutdown -c cancel am. When the machine return, confirm both sides:

uname -r
sudo canonical-livepatch status

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

Why old kernels still need cleaning out

Live patching dey 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 one boot image, one initramfs, one modules tree, and usually one headers package. For small VPS wey get separate /boot partition of some hundred megabytes, three or four of dem fit fill am.

Full /boot go then stop the next kernel installation, and na so machine fit become unable to take 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 kernel wey dey run and one known-good fallback, then remove the rest with the safe procedure for removing old kernels on Ubuntu. Never remove the kernel wey uname -r dey report currently.

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 direct: Livepatch “no be replacement for rebooting. Na tool wey give you more control by preventing unscheduled reboots.” Coverage go still end when dem retire your kernel series, and dem no dey live patch medium severity kernel fixes at all. Schedule maintenance reboot based on cadence wey you choose, instead make you wait until dem force am on you.

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

Run sudo canonical-livepatch status and read two lines. kernel state report whether the service cover your running kernel series, while patch state report whether the patches for that kernel don load. You fit also check the kernel side directly with ls /sys/kernel/livepatch/. E go list one directory for each loaded patch. Empty listing mean say nothing dey patched for memory right 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 e fit reach 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 listed as unfixed after Livepatch run?

Usually, na one of two reasons. The fix fit dey below the severity threshold, because Canonical live patch “kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings” and leave the rest for the package wey dey disk. Or the fix fit no be something wey you fit express as change to function body. For example, upstream fit don alter data structure, and live patching no fit safely change objects wey dem 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 dem don free dem from memory before the server come up.