Kernel livepatching swaps vulnerable kernel functions for fixed ones while the system runs, so you can apply some critical fixes without a reboot. It does not replace normal kernel updates. Only some fixes can be delivered this way, and the next planned reboot should still load a fully updated kernel.
Why it exists
The kernel documentation gives the motivation plainly: many users are reluctant to reboot, for example during heavy computation or peak load, yet they want a stable and secure system. Livepatching allows function calls to be redirected, so critical functions are fixed without a reboot.
How it works, in short
Livepatching builds on the kernel's dynamic function tracing facility (ftrace). A fixed version of a function is loaded in a module, and a hook at the start of the old function sends calls to the new one. Patches are applied per task, when each task is deemed safe to switch. The documentation says that after enabling, the system enters a transition state while tasks converge to the patched state, and that this usually completes in a few seconds.
That transition matters for complex fixes. The docs describe a consistency model, because a fix that changes locking order across several functions must switch all of them together and only when it is safe.
Documented limits
The same page lists limitations of the current implementation:
- Only functions that can be traced can be patched. Functions that implement ftrace or the livepatch handler cannot.
- The redirect must happen at the very beginning of the function, before the stack or parameters change, which depends on compiler support on each architecture.
- Kretprobes using ftrace conflict with patched functions, and the first user wins, so either the probe or the patch is rejected.
- Kprobes in the original function are ignored once code is redirected, and the docs say work is in progress to warn about this.
Beyond what the page says, think about scope. A livepatch is a targeted fix for specific functions. A fix that changes data structure layouts or needs new boot parameters is a poor fit, and distributions that offer livepatch services decide which fixes they ship this way. Check your provider's documentation for what is covered.
How to use it in practice
- Treat livepatch as a way to buy time for high risk kernel fixes, not as the end of patching.
- Check your distribution documentation for how patches are delivered and how to list what is applied. The kernel exposes state under sysfs for loaded livepatches.
- Keep a reboot window on the calendar, monthly or quarterly, so the running kernel catches up.
- Record which fixes were delivered live, and which kernel version the host is really on, in your asset record.
- After a reboot, confirm the new kernel with
uname -r.
Running a live patched kernel for a very long time means your uptime number looks great while the base kernel gets older. Auditors and responders both prefer a documented plan.
If you track patch metrics, see patch metrics that show risk, not just percent patched.
Safeguard offers asset discovery and zero-day discovery, and a free scan at gold.safeguard.sh/scan covers the dependency side.
Quick check
Can any kernel fix be delivered as a livepatch?
No. Only traceable functions can be patched, and fixes that change data layouts or other deep structure are a poor fit.
Does livepatching mean I never reboot?
It reduces forced reboots, but you still want planned reboots so the running kernel is fully updated.
Sources
Last reviewed: 19 October 2026.
