Kernel live patching on Debian, Ubuntu, RHEL and SUSE

You want kernel security fixes on the server without taking it down. Whether that is possible, and what it costs, depends mostly on which distribution you run. On Debian the answer is less obvious than the vendor pages suggest.

By David Kabel · Updated 2026-09-23 · 11 min read

Live patching swaps functions in memory

Many kernel security fixes are small: a missing bounds check, a NULL pointer check, a lock around a critical section. A live patch carries new copies of only the functions that changed, packaged as a kernel module. When the module loads, the kernel uses ftrace, its built-in hook at the entry of traceable functions, to send every call for the old function to the new one. Only the in-memory kernel changes. Nothing on disk changes, and uname -r still reports the same kernel.

The hard part is timing. A process can be halfway through the old function when the patch arrives, and switching it mid-function could leave it inconsistent. So the kernel switches each task separately, at a moment it knows is safe: when none of the patched functions are on that task's stack, or when the task next returns from the kernel to user space. The kernel documentation calls this the consistency model, a hybrid of SUSE's kGraft and Red Hat's kpatch. Usually every task has switched within a few seconds. A task stuck inside an affected function can hold the transition open indefinitely, so the kernel nudges blocking tasks with a fake signal every 15 seconds.

Limits of live patching

Not every fix fits. Live patching replaces functions, but data stays where it is. SUSE's documentation says data structures remain in place and cannot be extended or reinterpreted, so some fixes cannot become live patches and a restart is the only way to apply them. Functions the kernel cannot trace cannot be patched at all. When Canonical cannot build a live patch for a vulnerability, it publishes a notice telling you to update and reboot.

Only serious security fixes. Canonical live patches high and critical CVEs. SUSE targets CVSS 7 and above plus stability and data-corruption fixes, and says over 95% of qualifying fixes ship as live patches. Red Hat states that live patching does not address all critical or important CVEs. Canonical states that ordinary bug fixes, driver updates and lower-priority security fixes arrive only with a new kernel and a reboot.

Only the kernel. Canonical lists CPU microcode, shared libraries such as glibc, and BIOS or EFI updates as things that still need a reboot.

Patches for a kernel expire. Canonical builds live patches for a given kernel for 13 months after its release, or 9 months for HWE kernels. SUSE patches a kernel for 13 months, and a standard RHEL subscription covers it only until the next minor release. After that you install a newer kernel and reboot to stay covered. KernelCare patches each kernel for as long as its vendor ships security updates for that series.

Scanners still see the old kernel. Because uname -r does not change, Red Hat warns that vulnerability scanners may keep reporting the base kernel as vulnerable until you reboot. Expect that finding in audits and have the vendor's CVE list ready to answer it.

Your options by distribution in 2026

Ubuntu. Canonical Livepatch comes with Ubuntu Pro and covers Canonical's own kernels on LTS releases. Its supported-kernel table lists no interim releases. The personal Pro terms give a free subscription on up to five physical machines, and a company may hold only one such account. Canonical markets that tier as free for personal use, so read the terms before building a business on it. Free machines sit on the "updates" tier, which receives patches before paying customers on the "stable" tier. The client's own status output describes this as the machine beta testing new patches.

RHEL. kpatch is part of the subscription and arrives as ordinary RPMs. On RHEL 10, support starts with 10.2. If you stay on one minor release, you need Red Hat's extended support to keep receiving live patches for it. Red Hat does not support third-party live patches on RHEL.

SUSE. On SLES 15 SP7, Live Patching is a separate subscription registered as an extension. The SLES 16.0 documentation says it is included in the standard subscription. The initrd includes the active live patch, so an unplanned reboot into the same kernel comes back patched.

Debian. There are no official live patches. Two Debian developers filed an intent to package, bug 1070494, in May 2024 and presented the design at DebConf24. In February 2025 they reported that kpatch could not fully support trixie's kernel, which they said enables CONFIG_X86_KERNEL_IBT, and that they were looking at klp-build instead. Freexian's report published in July 2026 describes a Google Summer of Code student still comparing build tools. The kernel side is ready. Debian builds its amd64 kernels for bookworm and trixie with CONFIG_LIVEPATCH=y, and trixie ships kpatch 0.9.10. Bookworm has no kpatch package. You could build your own patches, but then you are the security team. You choose each fix, then build and test a module for every kernel version you run. In my view that is not realistic for a small business. Canonical Livepatch does not help either, because it only patches Canonical-released kernels.

KernelCare. TuxCare's service is commercial and covers the Enterprise Linux family, Ubuntu and Debian. Its supported-distributions page lists Debian 11, 12 and 13 as actively patched. The agent checks for patches every four hours. TuxCare says it must not run alongside Canonical Livepatch. On RHEL it is the third-party patching that Red Hat will not support.

Enabling the vendor options takes a couple of commands:

# Ubuntu LTS: attach to Ubuntu Pro, then switch Livepatch on
sudo pro attach YOUR_TOKEN
sudo pro enable livepatch

# RHEL: subscribe current and future kernels to live patches
sudo dnf install kpatch-dnf
sudo dnf kpatch auto

# SLES 16.0 (15 SP7 needs the Live Patching extension registered first)
sudo zypper install -t pattern kernel_livepatching

Check that a patch is loaded

A patch can be installed without being loaded. Patches that go through the kernel's livepatch subsystem appear under /sys/kernel/livepatch, one directory per patch module. Red Hat documents that its kpatch modules register there.

# Patches loaded through the kernel's livepatch subsystem
ls /sys/kernel/livepatch/
cat /sys/kernel/livepatch/*/enabled      # 1 = patched code is applied
cat /sys/kernel/livepatch/*/transition   # 0 = every task has switched over

If transition stays at 1, some task is still running old code. The kernel documentation shows how to find it through /proc/<pid>/patch_state. Do not write to the force file unless your patch vendor tells you to. Once you force a transition, you can never remove the patch module, and the documentation says to plan a reboot and apply no more live patches.

Each vendor also has its own status command. Use the one that matches your service, and put it in your monitoring rather than checking by hand:

canonical-livepatch status   # Ubuntu: coverage and patch state
kpatch list                  # RHEL: loaded modules show [enabled]
klp status                   # SLES
klp -v patches               # SLES: installed patches with their CVEs
kcarectl --info              # KernelCare: patches it has installed
kcarectl --uname             # KernelCare: the effective kernel version
cat /proc/kcare/cvelist      # KernelCare: CVEs the loaded patches address

On Ubuntu, read the kernel state line as well as the patch state line. It tells you whether the running kernel is still covered. Once it says the kernel is no longer covered, no new live patches will arrive until you upgrade and reboot.

Wardio uses KernelCare

Every machine Wardio manages runs KernelCare, and we chose it for coverage. We make no claim that it patches better than the vendors do. Most small-business servers are Debian or Ubuntu, of mixed versions, and Debian has no first-party option at all. One tool across all of them means one status command and one place to look when an auditor asks which CVEs are covered. The licence is part of the monthly price. If you run RHEL or SLES with a subscription, the vendor's own live patching is the sensible default.

Keep the reboot window

Live patching turns a kernel CVE from "reboot tonight" into "reboot at the next planned window". You still need that window to pick up fixes that could not be live patched, to move to a kernel before its live patch support runs out, and to load new glibc and microcode. Canonical also notes that enabling Livepatch does not turn on automatic installation of security updates in APT. If you are not sure yours are running, see what to check when unattended-upgrades is not working. Live patching is one step in securing a VPS, and it only pays off once the steps before it are in place.

Gotchas

• kpatch list succeeds with nothing loaded. On Debian 13 with kpatch 0.9.10 and no patch modules, kpatch list printed the headings Loaded patch modules: and Installed patch modules: with nothing under them, and exited 0. A monitoring check that only looks at the exit code passes on an unpatched machine; check for a module line ending in [enabled] instead.
• An empty glob is not a pass. With no patch loaded, cat /sys/kernel/livepatch/*/enabled prints No such file or directory for the literal pattern and exits 1, on Debian and Ubuntu alike. Make sure a script treats that as "not patched" rather than as an error to ignore.
• Bookworm and trixie kernels differ where kpatch cares. In the /boot/config-* files from Debian's kernel packages, bookworm's 6.1.0-53 has CONFIG_X86_KERNEL_IBT not set and trixie's 6.12.107 has it set to y. That is the option the Debian live-patching developers said kpatch cannot fully support. If you build your own patches, check grep CONFIG_X86_KERNEL_IBT /boot/config-$(uname -r) on the kernel you run.
• On Ubuntu, Livepatch changes the reboot flag. The kernel hooks that write /var/run/reboot-required on Ubuntu 24.04, in unattended-upgrades 2.9.1+nmu4ubuntu1 and update-notifier-common 3.192.68.2, skip writing it for linux packages when canonical-livepatch is installed and enabled. Going by those scripts, a new kernel on its own may not trigger unattended-upgrades' automatic reboot. We read this in the scripts themselves. We could not reproduce it because Livepatch cannot run in a container. Watch the kernel state line in canonical-livepatch status instead.

How this was tested. On 23 September 2026 we checked the Debian and command claims in Docker containers. On Debian 13, from the debian:trixie image, we installed linux-image-amd64 version 6.12.107-1 and kpatch 0.9.10-1. On Debian 12, from debian:bookworm-slim, we downloaded linux-image-6.1.0-53-amd64 version 6.1.187-1 and read its /boot/config. On Ubuntu 24.04.5 LTS we used ubuntu-pro-client 37.2ubuntu~24.04.1 to check the pro attach and pro enable livepatch syntax. We searched the whole Debian archive for a live-patch package with the ftp-master madison API, and checked dnf kpatch auto with kpatch-dnf 0.9.10 on AlmaLinux 10.2, a RHEL rebuild. Not tested: live patching itself, which needs a real kernel with livepatch support; canonical-livepatch, which is a snap and needs an Ubuntu Pro token; SUSE's klp and zypper pattern, which need a registered SLES system; TuxCare's proprietary kcarectl; and every subscription and pricing term, which we took from the vendors' pages listed below.

Sources

1. Livepatch, The Linux Kernel documentation, kernel development community
2. ABI: /sys/kernel/livepatch, The Linux Kernel documentation
3. Livepatch, Canonical
4. Kernels covered by Livepatch, Canonical Livepatch documentation
5. Updates not provided by Livepatch, Canonical Livepatch documentation, updated 18 June 2026
6. When to reboot, Canonical Livepatch documentation, updated 18 June 2026
7. How to check the Livepatch Client status, Canonical Livepatch documentation
8. Livepatch tiers, Canonical Livepatch documentation
9. Ubuntu Pro, personal: Terms of Service, Canonical
10. Managing, monitoring, and updating the kernel, chapter 9: Applying patches with kernel live patching, Red Hat Enterprise Linux 10 documentation
11. Managing, monitoring, and updating the kernel, Red Hat Enterprise Linux 9 documentation
12. Kernel Live Patching on SUSE Linux Enterprise Server, SUSE, SLES 16.0
13. Live kernel patching with KLP, SUSE, SLES 15 SP7 Administration Guide
14. Bug #1070494: ITP: linux-livepatching, Debian bug tracker, filed 6 May 2024
15. Linux live patching in Debian, DebConf24, 2 August 2024
16. Debian Contributions: Python 3.14 as default transition, DebConf 26 preparations, debvm, pconr and more!, Freexian, 15 July 2026
17. Debian kernel amd64 config, trixie branch, Debian kernel team
18. kpatch package, Debian package tracker, and madison query for kpatch and linux-livepatching, Debian FTP masters, checked 23 September 2026
19. KernelCare documentation, TuxCare
20. Supported distributions and lifecycle status, TuxCare