Linux Kernel Livepatching in 2026: kpatch, canonical-livepatch en Zero-Downtime Beveiligingspatches

Bijgewerkt: 8 september 2026

Linux kernel livepatching is een techniek waarmee je beveiligingspatches op een draaiende kernel toepast zonder de machine te herstarten, door binaire patches via de livepatch-subsysteemmodule in-memory in kritieke functies te injecteren. In deze gids leg ik uit hoe kpatch, canonical-livepatch en SUSE kGraft werken bovenop het upstream kernel/livepatch/ framework (aanwezig sinds Linux 4.0, met significante uitbreidingen in 6.x), welke CVE-klassen wél en niet livepatchbaar zijn, en hoe je de infrastructuur zelf uitrolt op RHEL 9, Rocky 10, Ubuntu 24.04 LTS en SLES 15 SP6.

• Kernel livepatching wisselt kwetsbare functies in een draaiende kernel om via ftrace-gebaseerde hooks; een reboot is niet nodig zolang de patch geen persistente datastructuren wijzigt.
• Sinds Linux 5.1 gebruikt het framework een hybrid consistency model (per-task, gebaseerd op klp_transition) dat semantische wijzigingen veiliger maakt dan het oorspronkelijke stop_machine-model uit 2015.
• kpatch 0.9.10 (juni 2026) ondersteunt kernel 6.9 en later; canonical-livepatch client 10.11 dekt Ubuntu 20.04 tot en met 24.04 LTS met 10 jaar levering onder Ubuntu Pro.
• Livepatches lossen circa 60–70% van de kritieke kernel-CVE's op; wijzigingen aan on-disk formaat, module-init, of vaste struct-lay-outs vereisen nog steeds een reboot.
• Op RHEL/Rocky/Alma bouw je patches met kpatch-build tegen de exacte kernel-devel-versie; distributies met FIPS-modus vereisen ondertekende livepatch-modules.
• Bewaking gebeurt via /sys/kernel/livepatch/ en het klp_patch tracepoint; integreer alerts in je bestaande auditd- of Prometheus-stack.

Wat is Linux kernel livepatching?

Kernel livepatching is het proces waarbij één of meer kernelfuncties op de plek worden vervangen door een gepatchte versie zonder de init-boom te onderbreken. Het upstream livepatch-subsysteem (geïntroduceerd door Josh Poimboeuf en Jessica Yu in commit b56b36ee6 voor Linux 4.0 in 2015) ontstond uit een samensmelting van SUSE's kGraft en Red Hats kpatch, plus lessen uit Oracle's oudere Ksplice-tooling. In 2026 bestaat er nog steeds precies één upstream framework (CONFIG_LIVEPATCH=y, x86_64, ppc64le, s390x en sinds kernel 5.10 ook arm64) waarop drie userspace-toolchains bouwen: kpatch, canonical-livepatch en klp-build-suse.

De praktische winst is operationeel. Eerlijk gezegd, toen ik dit voor het eerst uitrolde op een fleet van 2.000 edge-nodes verlaagde livepatching de MTTR van een externe kernel-CVE (denk aan CVE-2024-1086 in nf_tables of CVE-2025-21756 in vsock) van dagen naar uren, omdat je niet meer hoeft te wachten op een onderhoudsvenster. Livepatching vervangt géén reguliere kernel-upgrades. Je moet nog steeds herstarten om struct-lay-outs, boot-time features en __init-code te vernieuwen. Maar het kort het venster tussen CVE-disclosure en mitigatie fors in, wat direct meetelt in SOC 2- en NIS2-rapportages over patch cadence.

Hoe werkt kpatch onder de motorkap?

Onder de motorkap steunt kpatch op drie primitieven: ftrace, livepatch en module_layout. Wanneer je een livepatch als kernelmodule laadt (insmod kpatch-CVE-2025-38001.ko), registreert de module een struct klp_patch met daarin een lijst klp_objects (per doel-module of vmlinux zelf) en klp_func-entries. Voor elke functie wordt een ftrace-hook op de __fentry__-prologue geplaatst en gerouteerd naar de vervangende functie.

Het hybride consistency-model

Sinds kernel 5.1 (met belangrijke bugfixes tot en met 6.8) gebruikt livepatch een per-task consistency model: elke thread wordt gemarkeerd als "old" of "patched", en de overgang gebeurt pas als de scheduler de thread door een klp_check_stack()-punt laat gaan — meestal een syscall-exit of een ret_from_fork. Threads die uitsluitend in kernelspace draaien (kthreads, rcu_gp) worden expliciet gemigreerd door klp_transition_work_fn. Dit voorkomt de "half-oude, half-nieuwe stack"-race die het originele stop_machine-model in 2015 nog had.

Waar de gepatchte code fysiek staat

De vervangende functie leeft in het geheugen van de livepatch-module zelf, niet in vmlinux. ftrace zorgt voor de indirection: een call naar de kwetsbare functie wordt bij binnenkomst omgeleid via het ftrace trampoline, wat één extra jmp kost per aanroep — in de praktijk minder dan 1% overhead, ook op hot paths zoals tcp_recvmsg. Met perf stat -e cycles,instructions -a -- sleep 10 vóór en na het laden van een livepatch bevestig je dat op een moderne Xeon of EPYC.

kpatch installeren op RHEL 9 en Rocky Linux 10

Red Hat levert livepatches sinds RHEL 7.7 via de kernel-live-abonnementsstroom, en op RHEL 9.4+ met de kpatch-patch-*.rpm-modules die per kernel-uname -r gestreamd worden. Op Rocky Linux 10 en AlmaLinux 10 gebruik je de opensource kpatch-tooling zonder abonnement, maar je bouwt de patches zelf. Beide paden delen dezelfde userspace CLI.

Installeer eerst kernel-headers en het kpatch-pakket:

sudo dnf install -y kpatch kpatch-dnf kernel-devel-$(uname -r) elfutils-libelf-devel

# activeer het systemd-target dat livepatches bij boot toepast
sudo systemctl enable --now kpatch.service

# controleer status
sudo kpatch list

Voor de meeste teams is het waardevol om livepatches te versionen in git en via dnf-repo's te distribueren. Een minimaal ontwerp: publiceer per CVE een kpatch-patch-CVE-YYYY-NNNNN.el9.x86_64.rpm, laat kpatch-dnf automatisch de patch voor de huidige kernel binnenhalen, en configureer kpatch.service op LoadPatches=yes. Zo blijft je fleet compliant zonder handmatig ingrijpen. Dat is waardevol als je ook auditd voor kernelgebeurtenissen gebruikt om patching-events naar je SIEM te sturen.

Canonical Livepatch inschakelen op Ubuntu 24.04

Op Ubuntu 20.04 LTS tot en met 24.04 LTS levert Canonical livepatches via de canonical-livepatch-snap. Sinds Ubuntu Pro 30.x is de service gratis voor tot vijf machines per persoon; boven dat aantal geldt de betaalde tier. Client 10.11 (juli 2026) ondersteunt de HWE-kernel 6.8 en de nieuwe 6.11-kernel voor 24.04.3.

# koppel de machine aan Ubuntu Pro
sudo pro attach <YOUR_TOKEN>

# schakel livepatch in
sudo pro enable livepatch

# controleer welke patches actief zijn
canonical-livepatch status --verbose

De verbose-status toont voor elke patch de Fixes-lijst met CVE-nummers, de Kernel-versie waarop hij is gebouwd, en de State (applied, nothing-to-apply, of check-failed). Voor air-gapped omgevingen kun je patches via een lokale mirror serveren met de livepatch-onprem-container die Canonical sinds 2025 aanbiedt; dat vereist een Ubuntu Pro Infra-abonnement en werkt via een reverse proxy die de upstream livepatch.canonical.com-API spiegelt.

Zie de officiële Ubuntu Livepatch-documentatie voor de exacte CVE-dekkingsmatrix per LTS-kernel en de retentiestrategie (Canonical bewaart livepatches voor de duur van standaard- én extended-support, dus tot 2034 voor 24.04 LTS).

SUSE Live Patching op SLES 15 SP6

SUSE leverde in 2014 met kGraft de eerste productie-livepatchoplossing, en die codebase is inmiddels volledig geïntegreerd met het upstream livepatch-subsysteem. Op SLES 15 SP6 en openSUSE Leap 15.6 activeer je livepatching met:

sudo SUSEConnect --product sle-module-live-patching/15.6/x86_64
sudo zypper install kernel-livepatch-$(uname -r | tr - _)-default
sudo systemctl enable --now klp.service
sudo klp status

SUSE nummert livepatches sequentieel (livepatch-6_4_0-150600_23_25-default) en publiceert cumulatieve stacks: patch n bevat alle fixes uit n-1. Dit is anders dan Canonicals model waarbij elke fix in een eigen module leeft. In de praktijk vermindert het SUSE-model rebooteisen omdat je bij een reboot altijd de nieuwste kernel plus cumulatieve stack pakt, in plaats van een lange keten losse modules.

Elke livepatch-serie is gebonden aan een specifieke kernel-ABI-versie. SUSE geeft normaal 12 maanden aan livepatch-support per kernel voordat je moet upgraden. Plan die overgang in je onderhoudskalender, want een out-of-support kernel krijgt geen nieuwe patches meer, ook niet voor kritieke CVE's.

Een eigen livepatch bouwen met kpatch-build

Voor gepatchte kernels die géén distributie-livepatch krijgen (custom kernels, forks, oudere upstream-versies) bouw je zelf met kpatch-build. De workflow is simpel: haal de bron van de doelkernel, schrijf een unified diff met de fix, en laat kpatch-build een .ko-module produceren.

# clone kpatch en installeer buildafhankelijkheden
git clone https://github.com/dynup/kpatch.git
cd kpatch
sudo dnf builddep -y kpatch.spec   # of apt build-dep op Debian/Ubuntu
make

# schrijf je patch als een standaard 'diff -u' bestand
cat > fix-cve-2025-38001.patch << 'EOF'
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4321,7 +4321,7 @@ static void tcp_check_reno_reordering(struct sock *sk, const int addend)

        if (WARN_ON_ONCE(tcp_left_out(tp) > tp->packets_out))
                return;
-       tp->reordering = min_t(u32, tp->packets_out + addend,
+       tp->reordering = min_t(u32, max_t(u32, tp->packets_out, 1) + addend,
                               READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_max_reordering));
        tp->reordering_ts = tcp_jiffies32;
 }
EOF

# bouw de livepatch-module
kpatch-build/kpatch-build \
    -s /usr/src/kernels/$(uname -r) \
    -v /usr/src/kernels/$(uname -r)/vmlinux \
    --oot-module \
    fix-cve-2025-38001.patch

# laad en verifieer
sudo insmod kpatch-fix-cve-2025-38001.ko
cat /sys/kernel/livepatch/kpatch_fix_cve_2025_38001/enabled  # 1 = actief

kpatch-build compileert de kernel tweemaal (baseline en gepatcht), vergelijkt de object-files met create-diff-object, en verzamelt uitsluitend de gewijzigde functies plus hun relocaties in een minimale ELF-module. Bouwtijd is doorgaans 15–25 minuten op een 8-core builder. Voor CI/CD-integratie kun je dit combineren met je bestaande Trivy CI/CD-scanning-pipeline zodat elke kernel-CVE automatisch een livepatch-build triggert.

Is kernel livepatching veilig in productie?

Ja, mits je binnen de garanties van het framework blijft. Sinds het per-task consistency-model in kernel 5.1 is de kans op een corrupte stack tijdens transitie effectief nul geworden: threads komen pas op de nieuwe versie zodra hun aanroepstack schoon is. Google, Meta en Cloudflare draaien livepatch op honderdduizenden productieservers zonder gemelde livepatch-veroorzaakte kernel-panics sinds 2019.

Praktische risico's die je wel moet mitigeren:

1. Slechte patches: een livepatch is code als elke andere. Draai je patches minstens 24 uur op canary-nodes voordat je fleet-wide uitrolt.
2. Symbol drift: patches gebouwd tegen kernel A werken zelden op kernel B. Vergrendel kernelversies in je fleet met dnf/apt hold en versionlock.
3. Cumulatieve interacties: bij Canonical stapelen kleine patches, bij SUSE zijn ze cumulatief. Test transities tussen patchgeneraties, niet alleen de initiële load.

Voor kritieke workloads adviseer ik een tiered rollout: 5% van de fleet op T+0, 25% op T+24u, 100% op T+72u, en een geautomatiseerde rollback via echo 0 > /sys/kernel/livepatch/<patch>/enabled zodra je monitoring afwijkende oops-events oppikt in dmesg of via eBPF runtime-monitoring met Tetragon en Falco.

Welke CVE's kun je niet livepatchen?

Het framework kan géén livepatch produceren voor wijzigingen die de geheugenlay-out of levenscyclus van objecten aantasten. Concreet:

• Struct-veldwijzigingen: als een fix een nieuw veld toevoegt aan struct task_struct of struct sock, moet je herstarten omdat bestaande instances in het geheugen de oude lay-out hebben.
• __init-code: functies gemarkeerd als __init zijn na boot al vrijgegeven; ze kunnen niet gepatcht worden.
• Assembly-only paden: kpatch werkt op C-functiegranulariteit. Pure assembly-fixes (bijvoorbeeld in arch/x86/entry/entry_64.S) vergen een reboot.
• Module-init/exit: livepatches kunnen bestaande in-memory functies vervangen, maar kunnen de module_init-sequence van een reeds geladen module niet opnieuw laten draaien.
• On-disk formaatwijzigingen: filesystem-superblock- of inodewijzigingen zijn per definitie persistent; livepatch kan de code aanpassen maar niet bestaande on-disk state migreren.

Uit een steekproef van 2025 (Red Hat's CVE-mapping voor kpatch) blijkt dat ongeveer 65% van "important" en "critical" kernel-CVE's binnen deze grenzen valt en dus livepatchbaar is. De overige 35% vereist een reboot. Plan daarom nog steeds een kwartaal-onderhoudsvenster in.

Monitoring, auditing en compliance

Livepatching-audit gebeurt op drie niveaus: kernel (sysfs + tracepoints), userspace (klp-CLI-logs), en fleet (je patch-orchestrator). In /sys/kernel/livepatch/ vind je één subdirectory per geladen patch met enabled, transition (0=stabiel, 1=in transitie), en signals. Exporteer deze naar Prometheus met de node_exporter textfile-collector:

# /usr/local/bin/livepatch-metrics.sh
#!/bin/bash
OUT=/var/lib/node_exporter/textfile/livepatch.prom.$$
{
  echo "# HELP livepatch_enabled 1 als livepatch actief is"
  echo "# TYPE livepatch_enabled gauge"
  for p in /sys/kernel/livepatch/*/; do
    name=$(basename "$p")
    enabled=$(cat "$p/enabled" 2>/dev/null || echo 0)
    echo "livepatch_enabled{patch=\"$name\"} $enabled"
  done
} > "$OUT"
mv "$OUT" /var/lib/node_exporter/textfile/livepatch.prom

Draai dit script elke minuut via een systemd-timer. Combineer het met een Alertmanager-regel die afgaat wanneer livepatch_enabled == 0 op een node waar hij zou moeten draaien. Voor CIS-Benchmark 1.1.4 en NIS2-artikel 21 rapporteer je maandelijks de time-to-mitigation per kernel-CVE: het interval tussen NVD-publicatie en livepatch_enabled=1 op ≥95% van de fleet.

Voor forensische traceerbaarheid registreer je livepatch-load-events in auditd. De relevante syscalls zijn finit_module en delete_module; een regel als -a always,exit -F arch=b64 -S finit_module -F key=livepatch-load logt elke module-load, inclusief het EUID van de aanroeper. Zo koppel je livepatching aan je change-management pipeline en kun je onafhankelijk aantonen wie welke fix wanneer geactiveerd heeft.

Veelgestelde vragen

Wat is Linux kernel livepatching precies?

Livepatching vervangt kwetsbare functies in een draaiende kernel door gepatchte versies zonder reboot. Het gebruikt ftrace-hooks en het upstream livepatch-subsysteem (aanwezig sinds Linux 4.0) om aanroepen om te leiden naar code in een geladen kernelmodule.

Kost kernel livepatching prestaties?

De overhead per gepatchte functie is één extra jmp via het ftrace-trampoline, in de praktijk minder dan 1% op hot paths zoals TCP-receive of futex-wake. Meet dit zelf met perf stat -e cycles,instructions voor en na het laden.

Kan ik een livepatch verwijderen?

Ja: echo 0 > /sys/kernel/livepatch/<naam>/enabled deactiveert de patch, en rmmod verwijdert de module. Het transitieproces werkt in beide richtingen dankzij het per-task consistency-model.

Vervangt livepatching gewone kernelupdates?

Nee. Livepatches dekken alleen "hot" functiewijzigingen; struct-lay-outs, __init-code en on-disk formaten vereisen nog steeds een reboot. Zie livepatching als een manier om reboots te uitstellen, niet om ze te elimineren.

Werkt kernel livepatching op ARM64 en RISC-V?

ARM64 wordt ondersteund sinds kernel 5.10 (2020). RISC-V heeft experimentele livepatch-support sinds kernel 6.9 (2024), maar in 2026 leveren distributies nog geen productie-livepatches voor RISC-V. x86_64, ppc64le en s390x hebben volledige langlopende support.