Linux Kernel Live Patching 101: Fix Critical CVEs Without Reboot

 

Linux kernel vulnerability? Check if you're exposed (Ubuntu/Rocky/SUSE), auto-patch without reboot, mitigate with iptables, and build a test lab. Stop chasing CVE dates. Live patch workflow inside.

On April 9, 2026, SUSE released a live patch (SUSE-SU-2026:1237-1) for four kernel vulnerabilities, including a high-severity SUNRPC flaw (CVE-2025-71120, CVSS 8.7) that could crash NFS servers. Other fixed bugs affected traffic schedulers (sch_qfq, teql) and macvlan device creation.

But here’s the thing: kernel vulnerabilities are discovered every week. What matters isn’t the date – it’s having a repeatable process to check, fix, and verify without rebooting production servers.

This guide gives you that process – reusable today, next month, and next year.

How to Check If You Are Vulnerable (Commands for Ubuntu, Rocky, SUSE)

Run these commands to see if your kernel has unpatched flaws like the ones above (NULL deref, use-after-free, or broken error recovery).

Ubuntu 22.04 / 24.04

bash

# Check running kernel version
uname -r

# List available livepatch updates
sudo canonical-livepatch status

# See if a specific CVE affects you (example)
grep -i CVE-2025-71120 /boot/config-$(uname -r) 2>/dev/null || echo "Check Ubuntu CVE tracker"

Rocky Linux / AlmaLinux 8/9 (using kpatch)

bash

# Show loaded live patches
kpatch list

# Check kernel version against known vulnerable ranges
uname -r
# Compare with https://access.redhat.com/security/cve/CVE-2025-71120

SUSE Linux Enterprise / openSUSE Leap 15.4–15.6

bash

# List installed live patches
zypper se --details kernel-livepatch*

# Check if a specific live patch is loaded
sudo kernel-livepatch --verbose list
# Output shows which CVEs are covered (e.g., CVE-2025-71120, CVE-2026-22999)

Pro tip: Bookmark uname -r and your distro’s CVE database. That’s all you need for any future kernel bug.

Automation Script to Apply the Fix (Bash – Works on Major Distros)

Save this as apply-kernel-livepatch.sh – it auto-detects your distro and applies the correct live patch.

bash

#!/bin/bash
# apply-kernel-livepatch.sh - No reboot required
set -e

if [ -f /etc/os-release ]; then
    . /etc/os-release
    OS=$ID
    VER=$VERSION_ID
fi

case $OS in
    ubuntu)
        sudo canonical-livepatch enable YOUR_TOKEN_HERE
        sudo canonical-livepatch refresh
        ;;
    rhel|centos|rocky|almalinux)
        sudo kpatch install
        sudo kpatch update
        ;;
    suse|opensuse-leap)
        sudo zypper refresh
        sudo zypper install -t patch SUSE-SLE-Module-Live-Patching-15-SP4-2026-1237=1
        sudo kernel-livepatch --verbose load-all
        ;;
    *)
        echo "Distro not supported by this script. Manual update required."
        exit 1
        ;;
esac

echo "Live patch applied. Verify with:"
case $OS in
    ubuntu) sudo canonical-livepatch status ;;
    rhel|centos|rocky|almalinux) kpatch list ;;
    suse|opensuse-leap) kernel-livepatch list ;;
esac

Usage: chmod +x apply-kernel-livepatch.sh && sudo ./apply-kernel-livepatch.sh

Alternative Mitigation If You Can’t Update Now

Sometimes management says “no patches until next window.” Here are three immediate workarounds for the types of bugs in this SUSE update (network scheduler + RPC flaws).

1. Block vulnerable network schedulers (for CVE-2026-22999, CVE-2026-23074)

bash

# Prevent loading the 'teql' and 'qfq' schedulers
echo "blacklist sch_teql" | sudo tee -a /etc/modprobe.d/blacklist-network-sched.conf
echo "blacklist sch_qfq" | sudo tee -a /etc/modprobe.d/blacklist-network-sched.conf
sudo depmod -a
sudo reboot # or rmmod if not in use

2. Restrict NFS RPC calls (for CVE-2025-71120 – NULL deref in gss_read_proxy_verf)

Using iptables to allow only trusted NFS clients:

bash

# Allow only 192.168.1.0/24 to access NFS (port 2049) and RPC (port 111)
sudo iptables -A INPUT -p tcp --dport 2049 -s 192.168.1.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 111 -s 192.168.1.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 2049 -j DROP
sudo iptables -A INPUT -p tcp --dport 111 -j DROP

3. AppArmor profile for macvlan (for CVE-2026-23209)

bash

# Restrict which processes can create macvlan devices
sudo aa-complain /usr/sbin/ip
# Or create a custom profile that denies macvlan syscalls

Important: These are temporary. Live patch is still your long-term answer.

Suggested reading: 

Linux Kernel Programming by Kaiwan N. Billimoria - Amazon .

Why it helps: The four CVEs above come from memory corruption (NULL deref), use-after-free (qfq_change_class), and broken error recovery (macvlan). This book teaches you how to spot exactly those patterns in kernel code. You’ll go from “running a script” to understanding why the patch works – making you irreplaceable on your team.

Hands-on Lab: Reproduce & Fix a Kernel NULL Deref in a VM

Goal: Set up a vulnerable environment, trigger a similar bug, and test a live patch without touching production.

What you need:

Laptop with 8GB RAM

VirtualBox or KVM

Ubuntu 22.04 LTS ISO

Step-by-step:

1. Create VM (2 CPU, 4GB RAM, 20GB disk). Install Ubuntu 22.04 with default settings.

2. Downgrade kernel to a vulnerable version (example for CVE-2025-71120 style bug):

1. bash

   # In the VM
   sudo apt install linux-image-5.15.0-25-generic linux-headers-5.15.0-25-generic
   sudo reboot
   uname -r  # Verify 5.15.0-25

3. Install livepatch tooling:

1. bash

   sudo apt install snapd
   sudo snap install canonical-livepatch
   sudo canonical-livepatch enable [free trial token from ubuntu.com]

4. Simulate a NULL deref (safe version – won’t crash host):

bash

# Create a small kernel module that dereferences a NULL pointer
cat > null_deref.c <<EOF
#include <linux/module.h>
#include <linux/kernel.h>
static int __init init(void) {
    int *p = NULL;
    *p = 42;  // NULL deref
    return 0;
}
module_init(init);
MODULE_LICENSE("GPL");
EOF
make -C /lib/modules/$(uname -r)/build M=$(pwd) modules
sudo insmod null_deref.ko  # This will oops the VM

The VM will crash (dmesg shows “BUG: unable to handle kernel NULL pointer dereference”). That’s expected – you just reproduced a vulnerability class.

5. Apply a real live patch:

1. bash

   sudo canonical-livepatch refresh
   sudo canonical-livepatch status

6. Verify protection: Reboot, load the same module again. If the live patch covers it, the kernel will reject it or handle it gracefully.

Takeaway: You just simulated what attackers do – and how live patching stops them without a full reboot.

Conclusion 

You now have a battle-tested workflow for any kernel vulnerability:

• Check with uname -r + distro-specific commands.

• Apply live patches via the script above.

• Mitigate immediately with iptables/blacklists.

• Test safely in a VM lab.

But one-time fixes aren’t enough. Kernel CVEs drop every single month. Staying secure means having a repeatable system.