Step-by-Step: Implementing kpatch Livepatches on a Custom Debian/Ubuntu Kernel

Why I Refused to Reboot My Server at 3 A.M.

Last month my phone buzzed at 3:02 a.m. A critical kernel fix just dropped. Heart racing, I pictured the chaos:

30 minutes of downtime.

3,200 angry users on our streaming app.

Zero chance I was hitting that reboot button.

So I didn’t.

Ten minutes later the patch was live. Users kept watching cat videos. I went back to sleep.

Here’s the exact playbook I used—no fluff, just the steps that actually work on Debian/Ubuntu in 2025.

First, the Reality Check

CISA says 1 in 3 hacks start with an unpatched kernel. That’s not a headline; that’s Tuesday.

But rebooting? That’s expensive.

• A single e-commerce site lost $1.8 million during a 45-minute patch window last Black Friday.
• Netflix-grade traffic? Fifteen minutes down equals three hours of angry tweets and refunds.
• HIPAA or PCI auditors? They treat delayed patches like leaving your front door wide open.

Translation: you need zero-downtime fixes. That’s where kpatch comes in.

Think of kpatch Like a Band-Aid for Your Kernel

Instead of swapping the whole engine (reboot), you slap on a patch while it’s running.

Doesn’t work on every setup, though. Let’s fix that.

Step 1 – Is Your Kernel Patch-Ready?

Run this:

zcat /proc/config.gz | grep LIVEPATCH

You want to see:

CONFIG_LIVEPATCH=y

If you don’t, you’ll compile a new kernel once (I’ll show the cheat sheet later).

Step 2 – Install the Gear

sudo apt update && sudo apt install build-essential libssl-dev flex bison libelf-dev kpatch kpatch-dkms linux-headers-$(uname -r)

That pulls in kpatch-build, the little tool that turns a patch file into a kernel module.

Step 3 – Match the Kernel Source, Exactly

Your running kernel and source code must be twins.

uname -r

Grab the matching source:

cd /usr/src
sudo apt source linux-image-$(uname -r)

Then link it so kpatch-build can find it:

sudo ln -s /usr/src/linux-headers-$(uname -r) /usr/src/linux

Step 4 – Build the Patch

Grab the vendor’s .patch file. Mine was named cve-2025-1234.patch.

Build:

kpatch-build -t $(uname -r) -s /usr/src/linux-source-$(uname -r) cve-2025-1234.patch

Five minutes later you’ll get kpatch-cve-2025-1234.ko. That’s the magic module.

Step 5 – Apply It Live

sudo insmod kpatch-cve-2025-1234.ko

Check it stuck:

sudo kpatch list

No reboot. No dropped connections. Just a safer kernel.

Step 6 – Survive the Next Reboot

sudo cp kpatch-cve-2025-1234.ko /var/lib/kpatch/
sudo systemctl enable kpatch

Done. Next time the box restarts (for real maintenance, not panic), the patch loads automatically.

Common “Gotchas” I Hit So You Don’t Have To

Secure Boot

If your BIOS gripes about unsigned modules:

• Generate a MOK key once: openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500
• Sign the module: sbsign --key MOK.priv --cert MOK.der kpatch-cve-2025-1234.ko
• Reboot, enroll the key, and you’re golden.

Real-Time Kernels

RT kernels are twitchy. Test every patch in a lab clone first. If the latency jumps, roll it back:

sudo kpatch unload kpatch-cve-2025-1234.ko

Multiple Patches

Stacking is allowed, but each one adds weight. After three layers I schedule a proper kernel upgrade to keep things tidy.

Automation That Actually Saves Sleep

I wired GitHub Actions to:

1. Watch security mailing lists.
2. Auto-build patches when a new CVE hits.
3. Slack me only if the staging box passes 100% regression tests.

Net result: I patch within 6 hours of disclosure, zero human clicks at 3 a.m.

The Bottom Line

Custom kernel? No problem. kpatch turns scary CVE nights into five-minute coffee breaks.

Grab the checklist file here, plug it into your CI, and give your pager (and your sanity) a break.