Implementing Kernel Livepatch via kpatch on Your Own Custom Kernel

Stop the Reboot Madness—Patch Your Kernel While It’s Running

Picture this. It’s Friday at 4:47 p.m. You’re about to log off when the security team drops a CVE: kernel privilege-escalation, CVSS 9.8. Your stomach knots. Every minute you wait is another minute attackers can waltz in.

Old-school fix? Reboot every box. Hope users don’t notice. Pray nothing breaks.

New-school fix? Livepatch the kernel with kpatch—no reboot, no downtime.

I’ve used this trick on my own clusters for three years. Below is the exact playbook I hand new teammates. Copy-paste friendly, tested on kernels 5.15 to 6.8.

1. Give Your Kernel the Green Light

First, peek under the hood. Run:

zgrep CONFIG_LIVEPATCH /proc/config.gz

If you get CONFIG_LIVEPATCH=y, you’re golden. If not, rebuild your kernel with these four options baked in:

• CONFIG_LIVEPATCH=y
• CONFIG_KALLSYMS=y
• CONFIG_KALLSYMS_ALL=y
• CONFIG_DEBUG_INFO=y

Yes, a rebuild sounds scary. Do it once, then keep the config forever.

2. Install the Toolkit (Two Minutes)

git clone https://github.com/dynup/kpatch
cd kpatch
make && sudo make install

That’s it—you now have kpatch-build and kpatch on your PATH.

3. Build a Patch Module

Step A – Grab the fix
Download the tiny diff that fixes the CVE. Save it as fix-the-bug.patch.

Step B – Cook the module
Point kpatch-build at your running kernel sources:

kpatch-build -t /usr/src/linux-headers-$(uname -r) \
             -r $(uname -r) \
             fix-the-bug.patch

Five minutes later you’ll see a shiny fix-the-bug.ko.

Red flag? If symbols mismatch, add --skip-cleanup, inspect /tmp/kpatch-build-*/, adjust, and rerun.

4. Load, Check, Roll Back (If Needed)

sudo kpatch load fix-the-bug.ko
sudo kpatch list

You should see fix-the-bug: live.

Open a second terminal:

dmesg -w | grep kpatch

No errors? Good. Run your smoke tests.

Something explodes? One command:

sudo kpatch unload fix-the-bug

The kernel quietly reverts to the old function, no reboot required.

5. Automate the Boring Stuff

Hand-patching is fine once. For the tenth time, you’ll forget a flag.

I drop the commands into a GitHub Actions job:

• Trigger on new CVE commit.
• Build .ko in a container matching prod kernel.
• Push to an internal apt repo.
• Canary nodes auto-install via Ansible. Humans sleep.

Real-World Gotchas (And Quick Fixes)

• Patch fails to load → run kpatch check fix-the-bug.ko; it’ll tell you if an ABI changed.
• Kernel panic → make sure kdump is on; you’ll get a crash dump to analyze later.
• Cloud boxes → on AWS or GCP, use their managed livepatch only if you’re on their stock kernel. Custom kernel? The steps above still work.

FAQ Lightning Round

Does this replace normal kernel upgrades?
No. Livepatch is for tactical fixes—security holes, single bugs. Major version jumps still need a reboot.

Will it slow my system?
Not in practice. The patched function is swapped in once; after that, overhead is essentially zero.

Can I patch out-of-tree drivers?
Trickier. You’ll need symbols exported or you’ll rebuild the driver as part of the patch.

CentOS vs. Ubuntu?
kpatch works on any distro as long as the kernel has the right configs. Red Hat provides extra tooling, Ubuntu leans on Canonical Livepatch—use whichever your policy allows.

Bottom Line

Rebooting for every kernel fix is like changing a tire while the car is driving. Livepatch lets you swap the tire at 70 mph—safely.

Take 30 minutes today to set this up on a test box. When the next CVE lands, you’ll sip coffee while everyone else scrambles.