The Kernel Livepatching Subsystem: Applying Security Fixes to a Running Kernel Without Rebooting

2026-07-25

You have a fleet of 10,000 servers running a kernel with a freshly-disclosed CVE. Rebooting costs you a maintenance window, a rolling drain, and probably some customer trust. The alternative: livepatching, which swaps functions in a running kernel — no reboot, no downtime, no lost TCP connections.

The mechanism is deceptively simple. A livepatch is a kernel module containing the replacement function body plus metadata describing which symbol to redirect. Loading it invokes klp_enable_patch(), which walks the target function's prologue and patches in an ftrace call site — the same 5-byte NOP sled that CONFIG_DYNAMIC_FTRACE already sprinkles at the start of nearly every kernel function. That NOP becomes a CALL into ftrace's trampoline, which the livepatch code has registered to redirect execution to the new function.

The hard part isn't the redirect. It's consistency. If Thread A entered vulnerable_func() under the old rules and Thread B enters it a nanosecond later after the patch takes effect, and the two versions disagree about lock ordering or struct layout, you have chaos. Linux solves this with the consistency model borrowed from kGraft: every task is individually transitioned from "old universe" to "new universe" only when the kernel can prove that task is not currently executing (or waiting inside) any patched function. The proof comes from stack unwinding — the same DWARF-driven walk your debugger does — performed while the task is sleeping or trapped at a syscall boundary.

Concrete example: the 2018 CVE-2018-14634 (mmap overflow in load_elf_binary) was patched live on production Red Hat systems via kpatch-build, which diffed the pre/post source, compiled a module containing only the changed functions, and shipped it. Ubuntu's Livepatch service does the same via Canonical's cloud, pushing signed patches nightly.

Rule of thumb: livepatching works for self-contained function replacements. It cannot patch changes to data structure layouts, function signatures, or code paths that hold locks across the patch boundary. Roughly 90% of kernel CVEs fit this shape; the other 10% still need a reboot.

Cost per patched function: one indirect branch (predicted, ~1 cycle amortized) and a small ftrace bookkeeping hit. You pay in nanoseconds forever to save a reboot once — usually a great trade.

Check /sys/kernel/livepatch/ to see what's currently applied on your box. Empty directory means either no patches or your kernel was built without CONFIG_LIVEPATCH.

See it in action: Check out LIVE WEBINAR: The importance of live patching for Linux Kernel Vulnerabilities. by KernelCare to see this theory applied.
Key Takeaway: Livepatching redirects function entries through ftrace's NOP sleds and uses per-task stack unwinding to prove no thread is mid-execution in an old version before flipping it to the new one — trading a permanent 1-cycle indirect branch for eliminated reboots on ~90% of kernel CVEs.

All newsletters