How Kernel Live Patching Works on Linux

Objective

This guide explains how kernel live patching actually works, how to set it up on RHEL with kpatch and on Ubuntu with Canonical Livepatch, and where its real limitations are. By the end, you will know:

• What live patching can and cannot fix in a running kernel
• The exact commands to enable and verify live patching on both RHEL and Ubuntu
• The subscription and eligibility requirements for each
• Where live patching fits into a real patch management process, not as a replacement for reboots entirely
• Whether this is something RHCSA expects you to know

A critical CVE drops in the kernel. Production is up, customers are using it, and your maintenance window isn't for another two weeks. The old answer was: wait, accept the risk, or take an unplanned outage. Kernel live patching gives you a fourth option: patch the running kernel in memory, right now, with no reboot.

What Live Patching Actually Does

A live patch is a small binary module that gets loaded into the running kernel. It redirects specific vulnerable functions to patched versions of that same code, while the kernel keeps running. No reboot, no service interruption, no dropped connections.

What it is not: a general-purpose alternative to ever rebooting a kernel again. Live patching exists for a specific, narrow purpose.

• What it covers: security fixes and a defined class of bug fixes for the currently running kernel, specifically targeted at high and critical severity CVEs
• What it does not cover: kernel version upgrades, major structural changes to kernel data structures, driver updates, or anything that needs a different kernel binary entirely
• What it buys you: time. You close the security exposure immediately and schedule the actual reboot for your next planned maintenance window instead of an emergency one

Eventually you still reboot into the real updated kernel. Live patching doesn't eliminate that, it removes the urgency around it.

Part 1: kpatch on RHEL

How RHEL's Live Patching Works

Red Hat delivers live patches through a framework called kpatch. Patches arrive as RPM packages containing a kernel module, and that module is what gets loaded to redirect the vulnerable code paths.

A few facts worth knowing before you set this up:

• Subscription requirement: kpatch requires an active RHEL subscription. It's available across standard subscription tiers, not an extra add-on purchase.
• Not every CVE gets a live patch. Red Hat selectively issues live patches for important and critical CVEs, not the full stream of kernel updates.
• Live patches are cumulative. A new patch includes everything from the previous one plus the new fix, so upgrading the loaded patch is straightforward and safe.
• Eligibility is tied to specific base kernels. Red Hat designates certain errata kernels as kpatch-eligible on a quarterly cadence, and live patches are built against those specific base kernels, not every single kernel build that ships.
• Lifecycle matters. Once a RHEL minor version's support window closes (or the next minor version ships, depending on your subscription tier), new live patches for that older kernel generally stop, with rare exceptions for severe CVEs.

Setting Up kpatch on RHEL

# Verify your subscription is active
subscription-manager status

# Make sure the BaseOS repository is enabled
subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpms

# Install the kpatch DNF plugin
dnf install -y kpatch-dnf

# Confirm it installed correctly
rpm -q kpatch-dnf

Subscribing to the Live Patching Stream

# Automatically install live patches for your currently running kernel
dnf kpatch auto

# Search for available patches matching your kernel version
dnf search "$(uname -r)"

The kpatch auto command is the key step. It subscribes your installed kernels to the live patching stream, so future patch updates are picked up automatically through your normal dnf workflow rather than requiring a separate manual process each time.

Checking and Verifying Patch Status

# List all installed and currently loaded live patches
kpatch list

# Get detailed info on a specific patch module
kpatch info kpatch_5_14_0_1_0_1

# Confirm the kernel module is actually loaded
lsmod | grep kpatch

If kpatch list shows the patch as installed and loaded, the fix is active in the running kernel. No reboot has occurred, and none is needed for this specific CVE to be mitigated.

What Happens on the Next Reboot

This is a detail people miss: live patches are not a one-time injection that vanishes. A systemd service (kpatch.service) reapplies the live patch automatically when the system boots back into the same kernel. You don't lose the protection by rebooting for unrelated reasons, like an application deployment, the live patch reloads itself.

Part 2: Canonical Livepatch on Ubuntu

How Ubuntu's Live Patching Works

Canonical's equivalent is the Livepatch service, delivered as part of Ubuntu Pro. The mechanism is conceptually the same as kpatch: a signed kernel module patches vulnerable functions in the running kernel without a reboot, targeted specifically at high and critical severity kernel CVEs.

Key facts for Ubuntu:

• Free tier exists. Livepatch is available at no cost for up to 5 machines, intended for personal use or evaluation, through a free Ubuntu Pro subscription tied to an Ubuntu One account.
• Paid tier for production fleets. Beyond 5 machines, or for the broader Ubuntu Pro feature set (extended security maintenance for universe packages, FIPS-validated modules, CIS hardening profiles), you need a paid Ubuntu Pro subscription.
• LTS releases only. Livepatch targets Ubuntu LTS releases, not interim releases.
• Virtual machines inherit coverage. If the physical host is covered, VMs running on it are generally covered as well under server entitlements.

Setting Up Canonical Livepatch

# Attach the machine to your Ubuntu Pro subscription using your token
sudo pro attach YOUR_TOKEN_HERE

# Enable the livepatch service
sudo pro enable livepatch

You can get a free token by creating an Ubuntu One account and retrieving it from your Ubuntu Pro dashboard. Older documentation and some systems still reference the ua attach and ua enable livepatch commands. These are the same underlying tool; pro is the current command name, with ua retained as a compatibility alias on many systems.

Checking Livepatch Status

# Check overall Ubuntu Pro and service status
pro status

# Check Livepatch specifically, including currently applied patches
canonical-livepatch status --verbose

The verbose status output shows exactly which CVEs have been patched in the running kernel, when they were applied, and whether the kernel is current with available patches. This is your evidence trail for security audits and compliance reporting.

Side-by-Side: kpatch vs Canonical Livepatch

• Underlying mechanism
  • kpatch: kernel module redirecting function calls, delivered via RPM
  • Livepatch: kernel module redirecting function calls, delivered via Canonical's Livepatch service
• Distribution
  • kpatch: RHEL (and RHEL-derived distributions with their own equivalent tooling)
  • Livepatch: Ubuntu LTS releases
• Cost model
  • kpatch: included with active RHEL subscriptions, no separate purchase
  • Livepatch: free for up to 5 machines, paid Ubuntu Pro subscription beyond that
• Scope of coverage
  • kpatch: selected important and critical kernel CVEs against eligible base errata kernels
  • Livepatch: high and critical severity kernel CVEs
• Setup commands
  • kpatch: dnf install kpatch-dnf, then dnf kpatch auto
  • Livepatch: pro attach, then pro enable livepatch
• Status checking
  • kpatch: kpatch list, kpatch info
  • Livepatch: canonical-livepatch status --verbose

What Live Patching Cannot Do

This is the part that matters most for using it responsibly in production.

• It only patches the kernel. Userspace libraries, application dependencies, and other packages with their own CVEs still need normal patching and, where relevant, a service restart. Patching the kernel live while leaving a vulnerable library loaded in a running process accomplishes nothing for that second vulnerability.
• It cannot apply every kind of fix. Complex changes to kernel data structures or anything that fundamentally alters how the kernel manages state in memory generally cannot be expressed as a live patch. Those require an actual kernel upgrade and reboot.
• It has interaction restrictions. Tools like SystemTap and kprobes can conflict with a live patch while it's loading or active. Using these debugging tools at the same time can prevent the patch from applying correctly.
• It is not officially supported in every configuration. Some clustering and high-availability configurations have documented caveats around live patching cluster members. Check current vendor documentation for your specific HA setup before relying on it there.
• It does not remove the need to eventually reboot. Live patches buy time until your next planned maintenance window. They are a bridge, not a permanent substitute for keeping the actual installed kernel current.

Where Live Patching Fits in a Real Patch Process

The teams that get the most value from live patching don't treat it as a way to avoid reboots forever. They treat it as a way to remove urgency from reboots.

• Critical CVE drops: live patch applies within hours, closing the exposure immediately
• Normal maintenance window arrives: the system reboots into the actual updated kernel as planned, no emergency change request needed
• Userspace patching continues separately: library and application updates still follow your normal patch cadence, live patching doesn't change that workflow
• Audits stay clean: status commands on both platforms give you a clear, timestamped record of what was patched and when, useful evidence when a compliance review asks how quickly a critical CVE was addressed

This is the real value: it decouples "we are secure" from "we have scheduled downtime," which for uptime-SLA-bound production systems is often the entire problem live patching exists to solve.

Is Live Patching on the RHCSA Exam?

Short answer: not as a core tested objective. RHCSA's published exam categories focus on package management, storage, users, SELinux, networking, systemd, and the other topics covered throughout this series. Kernel live patching with kpatch isn't part of that core skill set, and it requires an active subscription to use at all, which doesn't fit cleanly into a standardized practical exam environment the way dnf or systemctl tasks do.

That said, it's worth understanding conceptually for two reasons:

• It reinforces a concept the exam does care about directly: the relationship between installed packages, the running kernel, and what state actually persists or applies without a reboot, the same persistence logic tested constantly elsewhere on the exam
• It's directly relevant once you're working as an actual RHCSA-certified administrator. Knowing kpatch exists, what it can and can't do, and how to check its status is a real production skill that comes up almost immediately in enterprise environments with uptime SLAs

Don't burn exam-prep hours drilling kpatch commands. Do understand what it is well enough to talk about it intelligently, since it's exactly the kind of practical, production-relevant topic that comes up in interviews after you're certified.

Quick Reference

• RHEL / kpatch:
  • subscription-manager status: verify active subscription
  • dnf install -y kpatch-dnf: install the plugin
  • dnf kpatch auto: subscribe installed kernels to live patching
  • kpatch list: show installed and loaded patches
  • kpatch info PATCH_NAME: detailed info on a specific patch
  • lsmod | grep kpatch: confirm the kernel module is loaded
• Ubuntu / Canonical Livepatch:
  • pro attach TOKEN: attach the machine to Ubuntu Pro
  • pro enable livepatch: turn on the Livepatch service
  • pro status: overall Ubuntu Pro service status
  • canonical-livepatch status --verbose: detailed patch history and current state

Conclusion

Kernel live patching solves a real, specific problem: closing a critical security gap immediately without forcing an unplanned outage on a production system. kpatch on RHEL and Canonical Livepatch on Ubuntu work on the same underlying principle, loading a signed kernel module that redirects vulnerable code paths while the system keeps running.

• It patches the kernel only, userspace still needs normal patching
• It covers selected high and critical CVEs, not every kernel update
• It requires an active subscription on both platforms, free for small Ubuntu deployments, included with RHEL subscriptions
• It removes urgency from rebooting, it doesn't remove the eventual need to reboot
• It's not core RHCSA material, but it's a skill worth having the moment you're managing real production systems

Used correctly, alongside a real patch management process rather than as a replacement for one, live patching is one of the highest-value tools available for keeping uptime-critical systems both secure and online at the same time.

Start building real-world Linux administration skills at LinuxCert.Guru → https://linuxcert.guru