Ubuntu Kernel Livepatch: Buying Time Without Replacing Reboots

You have a production host that cannot reboot during business hours, but a kernel CVE is published. The useful takeaway is that Ubuntu’s Kernel Livepatch can defer the reboot for a narrow set of kernel security fixes, not eliminate the need for reboots altogether. It is a scoped safety net for uptime-sensitive servers, not a general update mechanism.

The problem Livepatch is designed for

Kernel security updates normally require a reboot to load a new kernel image. For appliances, databases, and services with strict change windows, that reboot is the risk. Livepatch is Canonical’s service to apply select kernel security fixes to a running kernel by loading a cryptographically signed patch module.

Only stock Ubuntu kernels are eligible. Custom builds, third-party kernels, and end-of-life releases are excluded. Coverage is limited to specific CVEs that Canonical has produced as live patches for a supported Hardware Enablement kernel series. Hardware Enablement, or HWE, is Ubuntu’s rolling kernel track for LTS releases that keeps the kernel current on newer hardware.

How eligibility is enforced

Eligibility is tied to three things: the Ubuntu release, the running kernel series, and the Livepatch client state.

The client daemon canonical-livepatch checks in with Canonical services and applies signed patches to the live kernel. Authentication uses a token provided by Canonical. The system must stay on a supported stock kernel to remain in the patch window. Major kernel upgrades, driver changes, and user space security updates still require a normal reboot and package install.

Check if you are in scope before relying on it

Run these checks on the target Ubuntu host via SSH as a user with sudo privileges.

Confirm release and kernel series:

cat /etc/os-release
uname -r

This tells you the Ubuntu version and the running kernel, e.g., a 5.15 or 6.8 HWE series on an LTS. Livepatch support is documented per release for the supported HWE series.

Confirm the client is present and its state:

sudo canonical-livepatch status

With a valid token the client reports enabled and shows the kernel it is tracking. Without a token it reports disabled. Do not paste tokens in shared logs.

See what security updates are pending and whether any are livepatchable:

ubuntu-security-status

The output groups updates by type and can indicate which kernel fixes are available as live patches versus those requiring a reboot.

Risk note: enabling Livepatch with a token grants the daemon the ability to modify kernel code. Use a dedicated token per host or per fleet as appropriate for your policy, and rotate it if exposed.

Worked diagnostic decision

Scenario: a security advisory mentions a kernel privilege escalation. You want to know if Livepatch can defer a reboot tonight.

1. Verify release and kernel. If the host is an Ubuntu LTS on a supported HWE kernel, continue. If it is a custom kernel or EOL release, Livepatch will not apply.
2. Check canonical-livepatch status. If disabled, you can enable it with a token using sudo canonical-livepatch enable <TOKEN>. Token limits vary by Ubuntu edition and subscription.
3. Run ubuntu-security-status. If the specific CVE is listed as livepatchable for your kernel series, a patch can be applied without reboot. If it is not listed, plan a reboot window.

This decision flow avoids assuming coverage. It also makes clear that Livepatch does not cover user space packages, libraries, or applications.

Trade-offs and limitations

Livepatch applies only to the kernel. User space security updates still require normal apt upgrades and often service restarts.

Coverage is selective. Not every kernel CVE gets a live patch, and patches exist only for supported kernel versions within the release support window.

Operational constraints matter. Production use historically involves subscription and token limits that vary by release and edition. Custom kernels, live kernels, and kernels outside the HWE support window are not patchable.

Disabling Livepatch is done with sudo canonical-livepatch disable. There is no manual rollback of an applied patch module; the kernel is updated on the next reboot when you install the full kernel package.

Actionable closing: treat Livepatch as a deferral tool. Confirm eligibility with release, kernel series, and client status, use ubuntu-security-status to verify livepatchable coverage, and keep a planned reboot window for the full kernel upgrade and for all non-kernel security updates.