Kernel live patching

Why this matters for uptime-sensitive servers

The feature is also called livepatch, the name used in the Linux kernel documentation. See livepatch.

A kernel security fix traditionally requires a full reboot to take effect, which means a window of downtime, however brief, on every server that needs it. Live patching applies the fix to the running kernel in memory, avoiding that window entirely for supported updates.

Its limits

Not every kernel fix can be applied live; some structural changes still require a traditional reboot. Live patching is typically used to buy time until a scheduled maintenance window, rather than as a permanent substitute for eventually rebooting onto the fully updated kernel.

Our server patch management guide covers kernel live patching alongside regular reboots.

Check first whether your VPS can use it at all

Live patching changes the kernel your server is running, so it only makes sense if you control that kernel. The systemd documentation describes container virtualization (OpenVZ, LXC, Docker and similar) as shared kernel virtualization, which means a container-based VPS runs the host's kernel and only the provider can patch it. A full virtual machine, such as KVM, has its own kernel that you manage. Start with:

systemd-detect-virt
uname -r

# Ubuntu
sudo pro status
sudo canonical-livepatch status

# RHEL family
sudo kpatch list

According to Canonical's Livepatch how-to, sudo pro enable livepatch turns the service on, but patches are specific to a kernel version: on an unsupported kernel you can enable it and still receive nothing, and pro status prints a warning. The upstream kpatch list command shows installed patch modules on systems that use kpatch. Canonical's Livepatch page describes the free tier as covering up to 5 machines for personal use or evaluation, so check the terms before relying on it for a business server.

What a live patch does not do

The kernel's livepatch documentation explains the mechanism: a patched function is swapped in through ftrace, so only functions that can be traced can be patched. The switch happens per task when it is safe, usually within seconds, but a patch can stay in transition indefinitely if a task never reaches a safe point. The file /sys/kernel/livepatch/<patch>/transition shows that state.

Vendors limit the scope as well. The same Canonical page states that Livepatch targets kernel vulnerabilities with high or critical ratings that are practical to patch safely in memory, and it says plainly that the service is not a replacement for rebooting. Lower severity fixes wait for a normal kernel update. Keep checking whether the running kernel matches the installed one:

sudo needrestart -k

The -k option of needrestart checks for an obsolete kernel. Schedule the reboot in your patch window, and see the patch management guide for how live patching fits alongside it.

Related terms: Patch management, unattended-upgrades, Zero-day exploit, Livepatch.