Linux Kernel Live Patching Guide: What It Fixes and When to Reboot

Kernel live patching closes the window between a kernel fix being published and it running in production, but it is routinely mistaken for a reason never to reboot. Every major enterprise distribution now offers a live patching service, and each one states plainly that it reduces reboots rather than removing them. This guide explains how live patching works in the upstream kernel, what it can and cannot fix, how the four main distribution services describe their coverage, and how to build a patching policy that uses live patches for urgency and scheduled reboots for completeness. It is written for Linux platform engineers, vulnerability managers and auditors who need to know what "live patched" actually means for a given host. Services are listed alphabetically by vendor (Canonical, Oracle, Red Hat, SUSE), and order is never a ranking. Facts are taken from each vendor's documentation as of November 2026.

Key takeaways

• Live patches replace functions, not data. The upstream mechanism redirects calls to new function code through ftrace, so fixes that change data structures or initialisation code usually still need a new kernel and a reboot.
• Coverage is selective by design. Each vendor targets high-severity kernel vulnerabilities, and each says that not every fix is shipped as a live patch.
• Every patched kernel has an expiry. Live patches are built for a specific kernel build and are produced only for a limited period, so a host that never reboots eventually stops receiving them.
• "Patched" needs a different check. uname shows the booted kernel, not the effective one, so scanners and CMDBs must read the live patch state or they report false positives and false negatives.
• Policy pairs live patching with a reboot cadence. Use live patches to meet urgent remediation deadlines, and a scheduled reboot into the current kernel to pick up everything else.

How live patching works upstream

All four services build on, or work alongside, the Linux kernel's livepatch infrastructure, documented at docs.kernel.org.

• Function redirection: livepatch uses dynamic ftrace to redirect calls to a patched function to its new implementation. The redirect happens at the very start of the function, which is why only traceable functions can be patched; functions marked notrace, including the ftrace and livepatch handlers themselves, cannot.
• Consistency model: a patch is applied task by task. While a transition is in progress, the kernel checks whether a sleeping task has any affected function on its stack before switching it, which needs reliable stack traces; otherwise tasks switch on return from the kernel.
• Transition state: /sys/kernel/livepatch/<patch>/transition reads 1 while tasks are still converging and 0 when done; /proc/<pid>/patch_state shows each task's state. A transition that does not finish means the fix is not fully in effect. Forcing it through the force attribute is documented as a last resort that may be harmful.
• Taint: loading a live patch sets kernel taint flag K (bit 15, value 32768) in /proc/sys/kernel/tainted, a cheap fleet-wide signal that a host is running live patched code.
• Probe conflicts: kprobes in an original function are ignored once it is redirected, and ftrace-based kretprobes conflict with patched functions. Red Hat's documentation also advises against SystemTap or kprobes during or after loading a patch. This matters for observability and security agents that rely on kernel probes.

What live patching cannot fix

The kpatch project's patch author guide is the clearest statement of the limits, and it applies to the mechanism generally.

Shadow variables let a live patch attach new data to existing kernel objects without changing their layout, which is how some data-related fixes become live patchable. The kpatch guide is explicit that a patch that builds is not necessarily safe and that each needs analysis by a kernel expert; this is why vendors curate which fixes they ship.

Distribution services at a glance

The table records each vendor's own description of its service. It is not a comparison: coverage and terms differ because the distributions differ.

Canonical Livepatch

Livepatch is part of Ubuntu Pro. The client periodically checks for, downloads, verifies and installs patches for high and critical kernel vulnerabilities into the running kernel. The on-premises Livepatch server supports network-restricted and air-gapped environments, centralised distribution and staged rollout policies. Canonical states that security patches are created for a kernel for up to 9 to 13 months from its release, and asks users to upgrade and restart within that period to keep receiving them; supported kernels span Ubuntu LTS releases, with HWE kernels covered for specific combinations. Setup and Ubuntu-specific reboot handling (unattended-upgrades, needrestart, pro fix) are covered in the Ubuntu Server Security Hardening Guide.

Availability: requires an Ubuntu Pro subscription; check Canonical's supported kernels reference for the kernel flavours and releases covered.

Oracle Ksplice

Ksplice applies Critical, Important and select Moderate CVE fixes, based on Oracle Linux impact ratings, to "select, critical components" of a running system. The Uptrack client manages kernel updates (uptrack-upgrade -y to install, uptrack-show to list, uptrack-remove to back out). The Enhanced client's ksplice command covers kernel and user space subsystems; its documented targets include glibc and OpenSSL libraries in running processes. Ksplice reports an effective kernel version, from uptrack-uname -r or ksplice kernel uname -r, which differs from the boot version in uname -a and lets tools see that the kernel has been patched. Updates are cached in /var/cache/uptrack and reapplied early in boot; touch /etc/uptrack/disable or the nouptrack boot argument stops that.

Availability: included with Oracle Linux Premier Support and Oracle Cloud Infrastructure services; Basic, Basic Limited and Network Support subscribers can arrange Premier Support through Oracle sales. Check Oracle's maintained kernels list for coverage of a given kernel.

Red Hat kpatch

Red Hat Enterprise Linux delivers live patches as cumulative RPM modules named kpatch-patch-<kernel version>, with dots in the version replaced by underscores. Subscribe the running kernel with dnf install "kpatch-patch = $(uname -r)", or install the kpatch-dnf plugin and run dnf kpatch auto so current and future kernels are subscribed. kpatch list shows loaded and installed modules; empty subscription packages appear only in the RPM database. Red Hat supports only kpatch modules from its own repositories, describes live patching as intended for simple security and bug fixes when an immediate reboot is not possible, and states that reverting a live patch without a reboot is not supported: removing the package leaves the kernel patched until the next reboot. Distribution-wide hardening is covered in the Red Hat Enterprise Linux Security Hardening Guide.

Availability: live patches are available to all customers through normal channels; for a given minor release, standard subscriptions receive new patches until the next minor release ships, and extended support offerings extend that.

SUSE Live Patching

SUSE Linux Enterprise Server delivers Kernel Live Patching (KLP) as kernel-livepatch-* packages tied to an exact kernel revision, each cumulative, on AMD64/Intel 64, POWER and IBM Z. Every kernel update includes an empty initial patch that later fills with fixes. Fixes target SUSE CVSS v3.1 scores of 7 and above and bugs affecting stability or data corruption; SUSE states that over 95 per cent of qualifying fixes ship as live patches and that some are technically infeasible. Each live patch is updated for 13 months from the kernel package release, and expiry dates appear in zypper lifecycle. klp status checks state and klp -v patches lists the CVEs and defects addressed. SUSE states that data structure changes need a restart and that regular kernel updates still need a reboot.

Availability: requires active SLES and SLE Live Patching subscriptions, activated through yast2 registration or SUSEConnect and the lp_sles pattern.

When a reboot is still needed

• The fix is not shipped live: the vendor's advisory lists a kernel update but no live patch, typically for data structure or initialisation changes.
• The kernel's live patch window has expired: the kernel is older than the vendor's patch lifetime, so new fixes will not arrive.
• Non-kernel components changed: libraries, systemd, firmware and microcode updates need service restarts or a reboot, unless a user space live patching option covers that library.
• A transition did not complete: the livepatch transition attribute stays at 1 and tasks remain unpatched.
• Kernel version upgrade: moving to a new minor release or kernel stream always requires a reboot.
• Removing or rolling back a patch: Red Hat, for example, does not support reverting without a reboot.

Decision guidance

• Where live patching earns its cost: hosts where unplanned reboots are expensive or need change windows weeks away: databases, stateful clusters, telecoms and trading systems, hypervisors, and large fleets where a kernel CVE would otherwise trigger an emergency reboot campaign.
• Where it adds little: immutable or auto-scaled instances and Kubernetes nodes that are replaced from a new image more often than the patch window; rolling replacement is the cleaner fix there.
• Small organisations: enable the distribution's service on the handful of hosts that cannot reboot quickly, and keep a monthly reboot for everything else.
• Large organisations: treat live patching as a remediation path in the vulnerability process with its own evidence, stage patches through rings (an on-premises server or internal mirror helps), and set a maximum uptime or maximum kernel age so no host outlives its patch window.
• Remediation deadlines: a live patch can satisfy an urgent deadline, such as a known exploited kernel vulnerability, provided the vulnerability scanner and auditors can see the effective patch state. See Fixed Patch SLAs vs Risk-Based Remediation Windows and the Emergency Out-of-Band Patching Playbook.

How to implement

1. Inventory kernels: record booted kernel, distribution, subscription and uptime for every host, and identify which kernels are inside their vendor's live patch window.
2. Define the policy: which roles get live patching, the maximum kernel age or uptime (shorter than the shortest vendor window you use), and the reboot cadence that live patching does not replace.
3. Pilot: enable the service on a test ring that mirrors production kernels and agents. Confirm the transition completes, security and observability agents that use kprobes or eBPF still work, and performance is unchanged.
4. Stage through rings: apply new cumulative patches to the pilot ring first, then production, using staged rollout features or an internal repository.
5. Fix the reporting: make vulnerability scanners and the CMDB read the effective patch state (vendor status commands, effective kernel version, taint flag K) rather than uname alone.
6. Plan rollback: rollback for a faulty live patch is the vendor's documented removal or, where removal needs it, a reboot into the same or previous kernel; keep the prior kernel installed and test this in the pilot.
7. Keep rebooting: schedule reboots into the latest kernel so hosts reset their patch window and pick up fixes that never shipped live.

Detection and measurement

• Collect: per host, the booted kernel, effective kernel or patch list from the vendor tool, livepatch transition state, taint value, uptime and package update logs. Alert on transitions stuck at 1 and on hosts whose kernel is past its live patch window.
• Watch for tampering: unexpected kernel modules or live patches from unknown sources are a security event; kernel exploitation for privilege escalation (ATT&CK T1068) is the threat live patching mitigates. Pair with the Linux Detection and Response Guide.

Metrics:

1. Percentage of in-scope hosts whose kernel is inside its vendor live patch window.
2. Median time from vendor live patch release to applied on production hosts.
3. Percentage of high and critical kernel CVEs remediated by live patch versus by reboot.
4. Hosts above the maximum uptime or kernel age policy.
5. Count of incomplete live patch transitions in the last 30 days.

Common failure patterns

• Uptime as a trophy: hosts running for years on live patches, long past the patch window, still exposed to every fix that was never shipped live.
• Scanner disagreement: the vulnerability scanner reads uname, flags every live patched host as vulnerable, and the team learns to ignore kernel findings, including real ones.
• Subscription lapse: a renewal or registration lapses, patches stop arriving, and nothing alerts because the service still reports the last patch as applied.
• Probe conflicts unnoticed: a kprobe-based agent or SystemTap script stops a patch taking effect, as Red Hat's documentation warns, and no one checks the transition state.
• Kernel only: treating a live patched kernel as a fully patched host while glibc or OpenSSL fixes wait for restarts.

Framework mapping

See the CIS Control 7 Continuous Vulnerability Management Guide and the Patch Management Guide for the wider programme.

Where identity fits

Live patching services authenticate hosts with subscription and registration credentials: Ubuntu Pro attach tokens, Oracle and Red Hat subscription registrations, SUSE registration codes. These are machine credentials baked into images and automation, so keep them in a secrets manager, scope them per environment, and rotate them when staff or pipelines change. See the Linux Package Signing and Repository Trust Guide for the trust chain that delivers the patches themselves.

Practitioner checklist

• Every in-scope host has a recorded booted kernel, effective patch state and live patch window.
• A written policy sets which roles use live patching, a maximum kernel age and a reboot cadence.
• New live patches go to a pilot ring before production.
• Security and observability agents are tested against live patched kernels for probe conflicts.
• Vulnerability scanners and the CMDB read effective patch state, not uname alone.
• Alerts fire on stuck transitions, expired kernels and lapsed subscriptions.
• Rollback has been tested, including a reboot into the previous kernel.
• User space library fixes have their own restart path.

Standards and references

• Linux kernel documentation: Livepatch
• Linux kernel documentation: Shadow Variables
• kpatch project: Patch Author Guide
• Canonical: Livepatch supported kernels
• Oracle: Using Uptrack Commands to Manage Ksplice Updates
• Red Hat: Applying patches with kernel live patching
• SUSE: Kernel Live Patching
• Linux kernel documentation: Tainted kernels

Related NHI Mgmt Group resources: Patch Management Guide, Ubuntu Server Security Hardening Guide, Red Hat Enterprise Linux Security Hardening Guide, Linux Kernel Hardening and sysctl Guide.