In dieser Woche sind für zwei Sicherheitslücken Exploits verfügbar. Das erleichtert Angreifern das Erlangen von Root-Rechten und die Übernahme von SSH-Verbindungen.

Die Linux Foundation hat zusammen mit Industriepartnern wie Amazon Web Services, Anthropic, Cisco, Ericsson, Google, IBM, JPMorganChase, Microsoft, GitHub, NVIDIA, OpenAI, Red Hat oder der Rust…

OpenAI startet eine Preview-Phase für seine Modelle ChatGPT-5.6 Sol, Terra und Luna auf Weisung der US-Regierung für speziell ausgesuchte, besonders vertrauenswürdige Kunden.

Die Linux Foundation reagiert mit der Akrites Initiative auf wachsende Risiken für offene Software. KI findet Schwachstellen heute so schnell, dass klassische Sicherheitsprozesse kaum mithalten. Die Beteiligten warnen, dass moderne Modelle Lücken in Minuten aufspüren. Früher dauerte das oft viele Wochen. Diese Entwicklung trifft Bereiche wie Energie, Verkehr, Gesundheit und Finanzdienste. Gleichzeitig sinkt die Hürde […]

Der Beitrag Akrites Initiative: Neue Allianz will Open‑Source‑Sicherheit stärken erschien zuerst auf fosstopia.

Dieser Artikel richtet sich an jene, die sich für das Thema Kernel Live Patching (KLP) interessieren.

Im ersten Teil des Artikels stelle ich dar, wann KLP in meinen Augen keine gute Lösung darstellt und man auf den Einsatz nach Möglichkeit verzichten sollte. Wissend, dass es manchmal nicht anders geht, beschreibe ich im zweiten Teil am Beispiel von RHEL 9, wie KLP eingerichtet und genutzt werden kann.

Transparenzhinweis: Ich arbeite als Technical Account Manager (TAM) für die Firma Red Hat, welche die Distribution Red Hat Enterprise Linux (RHEL) herausgibt. Dieser Artikel spiegelt meine persönliche Meinung wider, welche mit der meines Arbeitgebers übereinstimmen kann, dies jedoch nicht in jedem Fall muss.

Der Userspace wird in diesem Artikel ausgeklammert, um den Umfang nicht zu sprengen. Ich werde diesen in einem folgenden Artikel aufgreifen.

Warum bzw. wann man Kernel Live Patching nicht nutzen sollte

Folgende Gründe sollten nicht zur Nutzung von KLP führen, sondern auf andere Weise adressiert werden:

• Angst vor dem Serverneustart
• Eine Softwarearchitektur, die Serverneustarts nicht vorsieht/zulässt
• Ungeklärte Abhängigkeiten in vernetzten Systemen
• Der Glaube, mit KLP nie wieder neustarten zu müssen

Angst ist in der IT ein ganz schlechter Ratgeber. Hier sollte unbedingt die Ursache und nicht das Symptom behandelt werden. Denn Serverneustarts können auch noch aus folgenden Gründen passieren bzw. notwendig werden:

• Der Server verliert vorübergehend die Stromversorgung
• Eine Kernel Panic bringt das System zum Absturz
• Ein nicht mehr reagierendes System muss durch einen Reset neugestartet werden
• Umzug der Hardware an einen neuen Standort

Dies sind nur vier Gründe, die mir sofort in den Sinn kommen. Wenn wir länger darüber nachdenken, fallen uns bestimmt noch viele weitere ein (ergänzt diese gern in den Kommentaren). Wichtig ist zu verstehen, dass Serverneustarts aus verschiedenen Gründen passieren und per se nicht schlimm sind.

Wenn die Softwarearchitektur keine Neustarts einzelner Komponenten zulässt, hat man ein ganz anderes Problem, welches dringend adressiert werden sollte. Soetwas wie 100%-tige Verfügbarkeit gibt es nicht. Hier ist in meinen Augen zu klären, ob es wirklich an der Anwendung oder eher an nicht verhandelten Wartungsfenstern liegt. KLP ist hier keine Lösung, da die Häufigkeit von Neustarts nur reduziert bzw. das Problem in die Zukunft verschoben wird.

Viele Sysadmins sind faul und das ist gut so. Motiviert es diese Personengruppe doch, manuelle Tätigkeiten zu automatisieren und sich die Arbeit zu erleichtern. Diese Faulheit darf allerdings nicht dazu führen, dass man sich vor der Analyse komplexer und vernetzter Systeme drückt. Abhängigkeiten können analysiert und in den meisten Fällen aufgelöst werden. Sind sie bekannt, kann man sie im Patchprozess berücksichtigen und den Vorgang inkl. Neustarts automatisieren. Auch in diesem Fall verzögert KLP das Unvermeidliche nur.

Kernel Live Patching kümmert sich, wie der Name schon sagt, nur um den Kernel. Was ist mit dem Userspace? Auch hier gibt es sicherheitskritische Bibliotheken und Anwendungen, wie z.B. openssl, gnutls oder die glibc, welche bei erkannten Schwachstellen zeitnah abgesichert werden müssen, um die Sicherheit des Systems nicht zu gefährden.

Neustarts sind per se nicht schlecht. Wer seine Server regelmäßig neustartet, gewinnt Vertrauen, dass diese auch wieder hochfahren und ihre Dienste korrekt erbringen. Schlummernde Probleme werden schneller erkannt und türmen sich nicht zu einem Störfall auf, der nur darauf wartet, im ungünstigsten Moment zu passieren. Und im Optimalfall sind die Dienste so entworfen worden, dass der Ausfall/Neustart eines einzelnen Servers nicht automatisch zu einer Nichtverfügbarkeit des Dienstes führt.

Ich möchte mein Plädoyer für Serverneustarts an dieser Stelle beenden und mich zwei Szenarios zuwenden, in denen KLP die Schmerzen des IT-Betriebs lindern kann.

Wann Kernel Live Patching Sinn macht

Für besonders geschäftskritische IT-Dienste existieren häufig Service-Level-Agreements (SLA), die eine sehr hohe Verfügbarkeit garantieren. Verstöße gegen diese SLA werden von den Stakeholdern meist nicht toleriert und sind in manchen Fällen mit Vertragsstrafen belegt. Zwar gilt auch hier, dass das Problem eher in der Softwarearchitektur liegt, doch hilft dies den Sysadmins nicht, die mit dem Betrieb beauftragt sind. Sie müssen irgendwie damit umgehen, bis eine bessere Lösung gefunden wird. Hier kann KLP eine Notlösung sein, um Sicherheitsrisiken im Betrieb zu reduzieren und SLA-Verstöße zu vermeiden.

Angelehnt an die SLA spielt die Zeit, die ein Server für einen Neustart benötigt, eine Rolle. Während die meisten VMs in Sekunden oder 1-2 Minuten neustarten, dauert dieser Vorgang bei Hardwareservern manchmal deutlich länger. Im Feld werden hier vereinzelt Zeiten zwischen 10-20 Minuten beobachtet (pro Server). Müssen mehrere Server für einen IT-Dienst sequentiell neugestartet werden, summieren sich die Zeiten schnell auf und machen größere Wartungsfenster erforderlich. KLP kann helfen, die Anzahl der langen Wartungsfenster zu reduzieren.

Es gibt Systeme, für deren Start ein manueller Eingriff durch Sysadmins notwendig ist. Dies kann z.B. die Eingabe eines BIOS-, Grub-, LUKS- oder UEFI-Passworts sein. Dies ist aufwändig und lästig, lässt sich aber leider nicht in allen Fällen wegautomatisieren. Auch hier erscheint es legitim, die Anzahl der manuellen Eingriffe durch den Einsatz von KLP zu minimieren.

Kernel Live Patching für RHEL 9 konfigurieren

Um mich für die Konfiguration vorzubereiten, habe ich folgende drei Quellen studiert:

• Chapter 9. Applying patches with kernel live patching
• Kernel Live Patch Support Cadence Update (Login erforderlich)
• Kernel Live Patch life cycles (Login erforderlich)

Die wichtigsten Erkenntnisse daraus sind für mich:

• Nicht jeder RHEL-Kernel erhält Live-Patches
• An jedem 1. März, Juni, September und Dezember (jedes Quartal) wird für jedes unterstützte RHEL-Release ein Kernel festgelegt, welcher Live-Patches erhält
• Für jeden dieser Kernel verspricht Red Hat bis zu einem Jahr lang Updates für CVEs, die nach Red Hats Ermessen als critical oder important kategorisiert wurden (siehe Severity Ratings)

Dass Red Hat für ausgewählte Kernel-Releases ein Jahr lang Live-Patches bereitstellt, lässt nicht den Schluss zu, nur noch einmal pro Jahr neustarten zu müssen. Denn:

• CVEs der Kategorien moderate und low werden gar nicht adressiert
• Man erhält keinerlei Bugfixes und keinerlei Produktverbesserungen (Red Hat Enhancement Advisories (RHEA))

Die Planung eines Neustarts wird jedoch ggf. vereinfacht.

Konfiguration von Kernel Live Patching für ein Labor-System

Ich habe ein Labor-System mit RHEL 9 auserkoren, welches als Hypervisor für einige Libvirt/KVM-VMs genutzt wird.

Dieses läuft aktuell mit dem Kernel 5.14.0-687.15.1.el9_8.x86_64, welcher laut Kernel Live Patch life cycles kein Kernel ist, für den KLP angeboten wird. Es ist also zuerst der kernel-5.14.0-687.10.1 zu installieren. Anschließend folge ich der Dokumentation, um den Live-Patch-Stream für diesen Kernel zu aktivieren (siehe folgender Codeblock).

~]$ sudo dnf search kernel-5.14.0-687.10.1.el9_8
Updating Subscription Management repositories.
Last metadata expiration check: 0:04:34 ago on Tue 23 Jun 2026 11:31:09 AM CEST.
================ Summary Matched: kernel-5.14.0-687.10.1.el9_8 ================
kpatch-patch-5_14_0-687_10_1.x86_64 : Initial empty kpatch-patch for
                                    : kernel-5.14.0-687.10.1.el9_8.x86_64
~]$ sudo dnf install kpatch-patch-5_14_0-687_10_1.x86_64

Wie im obigen Codeblock zu sehen, handelt es sich dabei um den initialen und leeren kpatch-patch. Das System hat also noch keinen Fix erhalten, sondern ist lediglich darauf vorbereitet.

Im jetzigen Zustand würde DNF das System bei einem Update jedoch auf die letzte verfügbare Kernelversion aktualisieren, welche keine Live-Patches erhält. Da dies von mir nicht gewünscht ist, aktiviere ich einen Filter, der zukünftig nur noch KLP-fähige Kernel anzeigt. Der folgende Codeblock zeigt den Zustand vor der Aktivierung des Filters, die Aktivierung selbst und den Zustand danach.

~]$ sudo dnf kpatch status
Updating Subscription Management repositories.
Last metadata expiration check: 0:04:36 ago on Tue 23 Jun 2026 11:43:44 AM CEST.
Kpatch update setting: auto-update
Kpatch filter setting: no-filter
Dependencies resolved.
Nothing to do.
Complete!

~]$ sudo dnf kpatch auto-filter
Updating Subscription Management repositories.
Kpatch filter setting: auto-filter

~]$ sudo dnf kpatch status
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Kpatch update setting: auto-update
Kpatch filter setting: auto-filter
Dependencies resolved.
Nothing to do.
Complete!

Zum Abschluss ein Neustart und mein System läuft mit dem richtigen Kernel 5.14.0-687.10.1.el9_8.x86_64.

Aufräumarbeiten

Aktuell sind auf meinem System noch Kernel-Pakete installiert, die für KLP nicht vorgesehen sind, aber bei einem dnf update aktualisiert werden würden:

~]# dnf list --installed kernel*
Updating Subscription Management repositories.
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Installed Packages
kernel.x86_64              5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel.x86_64              5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel.x86_64              5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64         5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64         5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64         5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-devel.x86_64        5.14.0-611.38.1.el9_7 @rhel-9-for-x86_64-appstream-rpms
kernel-devel.x86_64        5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-appstream-rpms
kernel-devel.x86_64        5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-appstream-rpms
kernel-headers.x86_64      5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-appstream-rpms
kernel-modules.x86_64      5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel-modules.x86_64      5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-modules.x86_64      5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64 5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64 5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64 5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-tools.x86_64        5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-tools-libs.x86_64   5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms

Um aufzuräumen, habe ich alle überflüssigen Pakte entfernt, bis nur noch der KLP-fähige Kernel vorhanden ist:

~]# dnf list --installed kernel*
Updating Subscription Management repositories.
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Installed Packages
kernel.x86_64                5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64           5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms
kernel-modules.x86_64        5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64   5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms

Verhalten bei zukünftigen Updates

Durch den konfigurierten kpatch-Filter werden bei zukünftigen Updates nur Kernel aufgeführt, die KLP-fähig sind. Wird ein KLP veröffentlicht, erscheint dieser als kpatch-patch in der Ausgabe von dnf up`. Der folgende (gekürzte) Codeblock zeigt dies beispielhaft.

~]# dnf up
Updating Subscription Management repositories.
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Dependencies resolved.
===================================================================================
 Package       Arch   Version               Repository                        Size
===================================================================================
Upgrading:
…
kpatch-patch-5_14_0-687_10_1 x86_64 1-1.el9_8 rhel-9-for-x86_64-baseos-rpms   22 k
…

Mit dem Befehl aus dem nächsten Codeblock kann kontrolliert werden, welche KLP aktuell installiert sind und welche CVEs sie adressieren.

~]# kpatch list
Loaded patch modules:
kpatch_5_14_0_687_10_1_1_1 [enabled]
	CVE-2026-43037

Installed patch modules:
kpatch_5_14_0_687_10_1_1_1 (5.14.0-687.10.1.el9_8.x86_64)

Obige Ausgabe bestätigt, dass ein KLP aktiv ist, der die kritische Schwachstelle CVE-2026-43037 schließt.

Fazit

KLP funktioniert und ist einfach einzurichten. Es ist nicht in jedem Fall die richtige Lösung und löst nicht alle Probleme, kann jedoch in manchen Fällen die Schmerzen im IT-Betrieb lindern.

Der Userspace wurde ausgeklammert, um den Umfang dieses Artikels nicht zu sprengen. Dies hebe ich mir für einen folgenden Artikel auf.

Nginx ist eine weit verbreitete Software für Webserver, Reverse-Proxy- und Load-Balancing-Dienste.

Die jetzt veröffentlichte Vollversion von OpenAIs neuestem Sicherheitsmodell GPT-5.5 Cyber soll das entsprechende Modell Mythos 5 von Anthropic hinter sich lassen, das eben noch nur ausgewählten…

Der Webserver Nginx weist zwei kritische Sicherheitslücken auf. Das Unternehmen F5 schließt diese mit Updates.

Das Arch User Repository (AUR) ist Ziel einer groß angelegten Malware-Kampagne geworden.

Google investiert zusammen mit den Partnern Stiftung Schmidt Sciences, der britischen Regierungsagentur ARIA, der Cooperative AI Foundation und unterstützt von Google.org 10 Millionen Dollar in…

Wieder einmal war das Arch Linux Community-Paketarchiv AUR Ziel eines Angriffs, bei den über 400 Pakete mit einer Dependency Credential Stealer Malware infiziert wurden.

Bei Ivanti Endpoint Manager Mobile (EPMM) handelt es sich um eine zentrale Verwaltungssoftware für Unternehmen.

Gogs ist eine leichtgewichtige, selbst gehostete Git-Plattform zur Verwaltung von Softwareprojekten und Quellcode-Repositories.

ChatGPT rollt für alle Accounts, die kostenlosen eingeschlossen, einen neuen Sperrmodus (Lockdown Mode) ein, der bis zu einem gewissen Grad vor Angriffen mittels Prompt Injection schützt.

Mehrere npm Pakete aus Red Hats Cloud Umfeld wurden manipuliert. Die Attacke schleuste heimlich Malware ein und gefährdete sensible Zugangsdaten. Laut Sicherheitsfirma Aikido tauchten die betroffenen Pakete Anfang Juni auf. Insgesamt waren viele Versionen verschiedener Bibliotheken kompromittiert. Die Schadsoftware befand sich in einem versteckten Installationsskript. Dieses lief automatisch beim Installieren der Pakete. Die Malware trägt […]

Der Beitrag Angriff auf Red Hat Cloud Pakete erschüttert Entwicklerwelt erschien zuerst auf fosstopia.

Die Abwehr von Schadcode konzentriert sich heute darauf, Hintertüren im Code zu entdecken.

Die Kette der durch KI-Tools entdeckten Schwachstellen im Kernel reißt nicht ab. Neuester Kandidat ist CIFSwitch, eine Lücke, die seit 2007 im Kernel schlummert.

Mit der vierten Vorabversion von Linux 7.1 meldet sich Linus Torvalds erneut zu Wort. Seine Botschaft richtet sich diesmal an alle, die Sicherheitsmeldungen mit KI Werkzeugen erzeugen. Der Kernel Chef sieht eine wachsende Belastung für das Projekt. Torvalds beschreibt eine Flut an Berichten, die oft das Gleiche melden. Viele Nutzer reichen identische Funde ein, weil […]

Der Beitrag Linus Torvalds: Linux Kernel Team kämpft mit KI erzeugten Sicherheitsmeldungen erschien zuerst auf fosstopia.

Kernel-Chefentwickler Linus Torvalds bittet, die private Security-Mailingliste nicht mehr unnötig mit KI-generierten Reports zu überfluten.

Mit Fragnesia ist eine weitere Variante der Linux-Kernel-Lücke Copy Fail bekannt geworden.

Ein frisch enthüllter Fehler im Linux Kernel sorgt erneut für Unruhe. Sicherheitsforscher von Qualys zeigen, dass ein normaler Nutzer unter bestimmten Umständen Dateien lesen kann, die eigentlich nur root sehen darf. Dazu zählen sogar private SSH Schlüssel, was die Tragweite des Problems deutlich macht. Der Angriff nutzt eine Schwachstelle in der Funktion __ptrace_may_access(), die in […]

Der Beitrag Neue Kernel Lücke erlaubt Zugriff auf sensible Systemdateien erschien zuerst auf fosstopia.

Die neu erschienene Version 7.3.0 des NAS-Betriebssystems erlaubt nun die Installation von internen Datenträgern und behebt die kritischen Sicherheitslücken Copy Fail und Dirty Frag.

Mit Dirty Frag ist erneut eine kritische Sicherheitslücke für Linux-Systeme aufgetaucht, über die Angreifer ihre Benutzerrechte bis hin zu Root-Rechten erweitern können.

Ein neues Sicherheitskonzept bewegt die Linux Gemeinschaft. Entwickler prüfen einen Vorschlag für einen Kernel Killswitch, der riskante Funktionen nach einer CVE Meldung sofort abschalten kann. Der Ansatz entsteht nach zwei frischen Schwachstellen, die zuletzt für viel Unruhe sorgten. Der Patch stammt von Sasha Levin. Er arbeitet bei NVIDIA und betreut den stabilen Kernel. Sein Vorschlag […]

Der Beitrag Killswitch Idee sorgt für Diskussion im Linux Kernel erschien zuerst auf fosstopia.

Ein neuer Fehler im Linux Kernel sorgt für Unruhe. Die Schwachstelle trägt den Namen Dirty Frag und ermöglicht lokalen Angreifern eine Privilegieneskalation. Sie reiht sich in eine Serie ähnlicher Probleme ein, die zuletzt mit Copy Fail bekannt wurden. Die Bandbreite der begroffenen Systeme ist weitreichend und umfasst z.B. Managed Servers, Container Hosts, CI Umgebungen und […]

Der Beitrag Dirty Frag legt neue Schwachstelle im Linux Kernel offen erschien zuerst auf fosstopia.