Canonical Livepatch in production — patching kernel CVEs without rebooting

The single longest-running argument in our team's history is about when to reboot a production database. The runner-up is what counts as "needing" a kernel patch. Livepatch settles roughly half of both arguments, and we use it on essentially every server in our managed Ubuntu fleet that supports it.

This post is what we actually know about it after running Livepatch on several thousand hosts for years, including the parts Canonical's marketing doesn't quite say out loud.

What Livepatch actually does

Livepatch is a kernel module that loads small binary patches into the running kernel without rebooting. When a CVE lands in a kernel function, Canonical's kernel team writes a patch, builds it as a livepatch module, signs it, and pushes it to the Livepatch server. Your machine's canonical-livepatchd daemon polls every few hours, downloads the module, and insmods it. The patched code now serves all future calls to that function. The old code is still in memory but unreachable.

It does not:

• Patch the bootloader, initramfs, or anything outside the running kernel
• Patch userspace libraries (glibc, openssl — those still need a package upgrade and service restart)
• Add new features, change kernel ABIs, or update third-party modules
• Replace eventual reboots — you still need to take the kernel upgrade and reboot every few months to consolidate patches

What it does do is collapse the window between "a kernel CVE is public" and "this machine is no longer exploitable" from "next maintenance window, possibly weeks" to "the next time canonical-livepatchd polls, typically under four hours."

The CVE coverage in practice

We pulled the numbers for one of our larger customer fleets across the last calendar year. Livepatch covered:

• 31 of 34 kernel CVEs rated High or Critical that affected the kernels we were running
• The 3 it didn't cover were either pre-disclosure embargoed patches that Canonical pushed via package upgrade instead, or CVEs in subsystems Livepatch can't safely modify (e.g., scheduling-critical paths)
• Mean time from CVE disclosure to livepatch availability: 2.4 days for High/Critical, longer for Medium
• Zero unplanned reboots attributed to kernel patching in that period

That's the value proposition in one paragraph: for the overwhelming majority of kernel CVEs, you can be patched within hours, without coordinating a reboot with the customer.

Enabling it — the modern way

On Ubuntu 22.04 and 24.04, Livepatch is part of Ubuntu Pro, and Pro is enabled via the pro CLI:

sudo pro attach <your-token>
sudo pro enable livepatch
sudo canonical-livepatch status --verbose

You should see something like:

client-version: 10.11.x
machine-id: 0123456789abcdef0123456789abcdef
machine-token: ********
architecture: x86_64
cpu-model: Intel(R) Xeon(R) CPU
last-check: 2026-05-12T03:14:22Z
boot-time: 2026-05-04T22:08:01Z
uptime: 7d18h6m21s
kernel: 6.8.0-58-generic
running-kernel: 6.8.0-58-generic
fixes:
- name: cve-2026-xxxx
  description: arch/x86: SVE register state leak
  status: applied
  patch-version: 109.1

status: applied is the one to alert on absence of. We pipe this into the host metrics collector via a five-line script:

sudo canonical-livepatch status --format json \
  | jq -r '.Status[0].Livepatch | "livepatch_state=\(.State) livepatch_fixes=\(.Fixes|length)"'

If livepatch_state is anything other than applied or nothing-to-apply, we get paged.

Pro subscription — what you're actually buying

Ubuntu Pro at fleet scale is a per-machine subscription. As of 2026 the rough pricing is around USD $25/machine/year for the Infra tier, less for desktops, with discounts at volume. For that you get:

• Livepatch (the headline feature)
• ESM — extended security maintenance for the ~25,000 packages in universe, including critical libraries that Canonical doesn't patch in the free -security pocket
• FIPS-validated kernel and crypto modules for the compliance-bound subset of customers
• CIS hardening profiles delivered via usg (Ubuntu Security Guide)
• 10 years of security maintenance per LTS release instead of the free 5

For a server you're paying real money to run anyway, Pro is the single best dollar-per-CVE-mitigated spend on Ubuntu. We bundle it into every managed tier by default and have done since it stopped being "Advantage" and became "Pro" in 2022.

The reboot Livepatch doesn't eliminate

This is the part that surprises people. Livepatch is excellent for the acute CVE window. It does not let you run a single kernel for years. You still need to:

1. Take the new kernel package via apt when one is released (linux-image-generic etc., assuming you've not blacklisted it — see the previous article in this series)
2. Reboot to that new kernel within a sensible window (we target 90 days max per host, with most rebooting within 30)
3. Livepatch on the new running kernel resumes covering future CVEs

If you skip step 2, Livepatch eventually runs out of patches for your stale kernel and you're back where you started. Livepatch is a bridge across a maintenance window, not a replacement for ever rebooting.

We track "days since last reboot" as a fleet metric and have an SLO that no server exceeds 120 days. The actual median across our fleet is around 22 days, mostly driven by general maintenance and rolling deploys rather than kernel-specific reboots.

What about workloads that genuinely can't reboot?

The classic case: a stateful single-node database, or a customer who simply won't authorize a maintenance window short of a P1 incident. We have two patterns:

• Replicate, then rotate. Stand up a replica on a current kernel, fail traffic over, and now the formerly-stuck primary is no longer load-bearing and can be rebooted at leisure. The right answer for any database older than the application using it.
• Livepatch for the duration, with a hard expiry. We accept the stale-kernel risk for a defined window (max 180 days), with explicit customer sign-off, and a calendar item to revisit. Livepatch keeps the box patched against everything Canonical writes a livepatch for, which in practice is most of what matters.

Either way, the cybersecurity team owns the exception register and reviews it monthly.

Alternatives, briefly

If Pro is off the table — license issue, air-gapped environment, RHEL-aligned compliance program — here are the live-patching alternatives we've used in anger:

• kpatch (Red Hat, but works on Ubuntu) — open source, requires you to build the patches yourself from upstream stable trees. Effort: high. Skills: kernel-developer-adjacent. Useful for one-off custom kernel scenarios, not a fleet solution.
• KernelCare (TuxCare) — commercial third-party live patching, works on Ubuntu, RHEL, CentOS, AlmaLinux. Reasonable alternative if you need a single vendor across a mixed Linux estate. We've deployed it for a couple of customers running both Ubuntu and RHEL-family and the experience is similar to Livepatch with slightly different CVE coverage and pricing.
• Oracle Ksplice — works on Oracle Linux and (with a subscription) on Ubuntu. Mature tech, predates Livepatch by years. Niche outside Oracle shops in 2026.
• Just reboot more often — perfectly valid for stateless workloads. If your fleet is autoscaling stateless workers behind a load balancer, "we replace nodes every 7 days" is operationally simpler than any patching subscription. We run several customer environments this way.

The decision tree is: is this a workload where unscheduled reboots are unacceptable? If yes, Livepatch (or KernelCare). If no, you can just patch and reboot on a cadence and skip the subscription entirely.

The failure modes we've actually seen

Livepatch is mature and reliable, but it's not invisible. The real-world failure modes:

• Polling stalled. The daemon stops checking in — usually a transient outbound HTTPS issue, sometimes a clock skew breaking TLS. Caught by our last-check > 24h alert. About 1-2 hosts per thousand per month.
• Livepatch refused to load. A handful of times across years, the daemon reports unable to apply for a specific fix. Always a known limitation that Canonical publishes — they fix it within a day or two, or ship the patch as a kernel package instead.
• Token expired silently. A Pro token rotation that didn't propagate. We catch this with monthly attestation runs that re-validate pro status --all.

None of these is catastrophic. All are visible if you monitor canonical-livepatch status per host, which you should.

The takeaway

If you run Ubuntu in production, run Pro, and run Livepatch. The combination of same-week ESM patches for universe packages, hours-not-weeks kernel CVE response, and a controlled-cadence reboot policy is meaningfully better than the same fleet running on free Ubuntu — and the cost is small relative to the engineering hours you'd spend coordinating emergency reboots three or four times a year.

If you'd like us to roll this out across your fleet — Pro attachment, fleet-wide Livepatch monitoring, reboot orchestration, and CVE response integration — that's exactly the kind of work the server management tier is built around.

Sudhanshu K. is a principal engineer at EdgeServers (RemotIQ Pty Ltd, ABN 91 682 628 128). He has read more kernel oops messages than he cares to admit and once kept a server up for 1,184 days, which he now considers an anti-pattern.