Livepatch

What Livepatch is and how its three pieces fit

The word "livepatch" covers three related things. The first is the upstream facility in the Linux kernel. The kernel documentation describes it as redirecting calls from a vulnerable function to a fixed one, built on ftrace, with each task switched over only when that is safe. The second is Canonical Livepatch Service, delivered through Ubuntu Pro. Canonical says it targets critical and high severity kernel vulnerabilities that can be patched safely in memory. The third is kpatch, which Red Hat's documentation calls the only live patching utility it supports for its RPM modules, shipped as kpatch-patch packages.

All three share one boundary: they change selected kernel functions and nothing else. Canonical notes that userspace libraries such as OpenSSL or glibc are not covered, so they still arrive through unattended-upgrades or a normal package update. The idea behind all of it is explained on the kernel live patching page; this page is about the tools.

How to enable Livepatch and check its status

On Ubuntu, Canonical's Pro client guide says Livepatch is enabled by default after you attach Ubuntu Pro, and that enabling it by hand installs the canonical-livepatch snap. On RHEL-family systems, Red Hat's guide installs the kpatch-dnf plugin, subscribes all installed kernels to live patches, and installs the patch for the running kernel.

# Ubuntu (the token comes from the Ubuntu Pro dashboard)
sudo pro attach TOKEN
sudo pro enable livepatch
pro status
sudo canonical-livepatch status --verbose

# RHEL family
sudo dnf install kpatch-dnf
sudo dnf kpatch auto
sudo dnf install "kpatch-patch = $(uname -r)"
kpatch list

In the Canonical output, the kernel state line says whether your kernel series is covered, and the patch state line says whether patches are applied or none exist yet. Problems are logged by the snap service: journalctl -f -u snap.canonical-livepatch.canonical-livepatchd.

Limits and gotchas

• Kernel specific. Canonical patches are tied to the kernel version. On an unsupported kernel you can enable the service and receive nothing, and pro status shows a warning. It is not compatible with FIPS-certified or real-time kernels.
• Version string does not change. Red Hat warns that uname -r stays the same after a live patch, so external scanners may still flag the base kernel. kpatch list shows loaded and installed modules, and since kpatch 0.9.10 the CVEs fixed by each loaded module.
• No rollback without a reboot. Red Hat does not support reverting live patches without rebooting, and says not to use SystemTap or kprobe during or after loading a patch.
• Coverage ends. On a standard Red Hat subscription, access to new patches for the current minor release stops when the next minor release ships.
• Transitions can stall. Upstream, a patch switches tasks one by one. The file /sys/kernel/livepatch/<patch>/transition shows 1 while that is in progress.
• Shared kernels. On a container VPS the kernel belongs to the host.

Where Livepatch fits in hardening

Treat Livepatch as a stopgap inside patch management, not a way out of it. Canonical states that it is not a replacement for rebooting and recommends scheduled reboots to clear accumulated state. A sound order is: automate package updates, let Livepatch cover the gap for high and critical kernel fixes, then install the new kernel and reboot in your patch window. After a reboot, confirm the running kernel matches the installed one.

Use exploitation data to decide how fast to move. A kernel flaw that is already being used against servers is an n-day exploit in practice, and the CISA KEV guide explains how to rank such fixes. Alert when canonical-livepatch status reports an error state, as covered in the monitoring guide. The full routine, including verification, is in the server patch management guide, and the baseline checks are in the VPS security checklist.

Related terms: Kernel live patching, Patch management, unattended-upgrades, Patch window, N-day exploit.