Durchgesickerte Berichte zum Linux-Kernel enthalten zwei ksmbd-Fehler und einen Root-Exploit, der den „Dirty Frag Fix“ umgeht

Die Kurzfassung

Zur Langfassung springen ↓

Was geschah: Am 20. und 21. Oktober 2026 (UTC) sendete die Zero Day Initiative (ZDI) von Trend Micro sechs Schwachstellenberichte an das Kernel-Sicherheitsteam und versehentlich auch an öffentliche Mailinglisten, darunter LKML und netdev. Bei fünf handelt es sich um Kernel-Fehler, einer betrifft ConnMan, einen Netzwerkmanager im Userspace. Keiner der Berichte enthielt einen Patch, keiner hat bisher eine CVE-Nummer, und drei enthielten den vollständigen PoC-Quellcode. Phoronix berichtete am 22. Oktober darüber. Zu diesem Abschnitt springen →

Der entscheidende Punkt:ZDI-CAN-33367 ist ein Fehler im Netzwerk-Helper „skb_zerocopy“, der es einem lokalen Benutzer ohne Sonderrechte ermöglicht, in den Seiten-Cache einer Datei zu schreiben, auf die er nur Lesezugriff hat. Gehört zur gleichen Klasse wie „Dirty Pipe“ und ist nur einen kleinen Schritt von Root-Rechten entfernt. TuxCare hat den Fehler intern bis hin zu einer Root-Shell reproduziert; er umgeht den im Mai veröffentlichten Fix für „Dirty Frag“ (CVE-2026-43284), und als die Berichte veröffentlicht wurden, war noch kein Fix in den Upstream-Code integriert oder in einem Distributions-Kernel ausgeliefert worden. Es handelte sich also tatsächlich um einen Zero-Day. Zu diesem Abschnitt springen →

Wer ist betroffen: In den Tests von TuxCare erlangte der Exploit Root-Rechte unter AlmaLinux 8, 9 und 10, CloudLinux 9 und 10, Debian 12 und 13 sowie Ubuntu 24.04 und 26.04, wobei er die AppArmor-Einschränkungen von Ubuntu umging. Die Kernel von CentOS 6 und 7 sind nicht anfällig. CloudLinux 8, das alle vom Exploit benötigten Module enthält, sowie Ubuntu 22.04 wurden noch nicht getestet. Zu diesem Abschnitt springen →

Was ist mit den 9,0-ksmbd-Ergebnissen: Bei beiden muss der SMB-Server im Kernel laufen, und dieser bleibt deaktiviert, sofern ein Administrator ihn nicht bewusst aktiviert hat. Die öffentlich zugänglichen PoCs zeigen eher ein Heap-Leck im Kernel und Abstürze als eine Codeausführung, was jedoch nicht ausschließt, dass Schlimmeres passieren könnte. Zu diesem Abschnitt springen →

Der aktuelle Stand: Für ZDI-CAN-33367 gibt es noch immer keine CVE-Nummer. Der Upstream-Fix wurde in den Netzwerk-Zweig des Kernels aufgenommen, hat aber noch nicht den Mainline-Zweig erreicht. AlmaLinux 9 wurde mit einem gepatchten Kernel ausgeliefert, AlmaLinux 10 noch nicht. Der rebootless-Patch von KernelCare ist für EL10 und EL9 verfügbar, für EL8 steht die Veröffentlichung kurz bevor, und die Arbeiten an Debian und Ubuntu sind im Gange. Bis zum 27. Oktober wurden keine Ausnutzungen in freier Wildbahn gemeldet. Zu diesem Abschnitt springen →

Was heute zu tun ist: Prüfen Sie, ob Namespaces für Benutzer ohne Sonderrechte aktiviert sind, und deaktivieren Sie diese auf Hosts, die sie nicht benötigen. A 0 Das bedeutet, dass keine neuen Benutzernamensräume erstellt werden können, was den öffentlichen PoC verhindern sollte:

sysctl user.max_user_namespaces

Zu diesem Abschnitt springen →

Lokale Sicherheitslücken, die eine Rechteausweitung ermöglichen, werden oft als Problem der nächsten Woche abgetan. Man geht davon aus, dass man dafür zunächst eine Shell benötigt – und wenn man bereits eine hat, gibt es viel größere Probleme.

Diese Logik zieht auf den Hosts, auf denen KernelCare normalerweise läuft, nicht. Ein Shared-Hosting-Server mit 300 cPanel-Konten verfügt von Haus aus über 300 lokale Benutzer, und jeder einzelne von ihnen kann PHP oder einen Cron-Job ausführen. Ein CI-Runner führt alles aus, was ihm ein Pull-Request vorschreibt. Ein Login-Knoten einer Universität dient dazu, Shells zu vergeben. Bei all diesen Fällen bedeutet „lokaler Benutzer“ einfach „Kunde“ oder „Job“, und ein funktionierender Schreibzugriff auf den Seiten-Cache kann jedem von ihnen Root-Rechte verschaffen.

Das ist das Problem bei ZDI-CAN-33367. Der Bericht, die Analyse und der PoC-Quellcode tauchten in öffentlichen Kernel-Mailinglisten auf, bevor es einen Fix gab. Normalerweise wird zuerst der Patch veröffentlicht und erst danach folgen die Details. Diesmal war es genau umgekehrt.

Der Kernel-eigene Leitfaden zur Meldung von Sicherheitsfehlern fordert die Melder auf, diese vertraulich an die Subsystem-Betreuer und das Kernel-Sicherheitsteam zu senden – nicht an eine öffentliche Liste – und keine Informationen zur Reproduktion preiszugeben. Auf diese Weise kann ein Fix bereitstehen, bevor andere die Details einsehen können. ZDI verfährt normalerweise genauso. Seine Offenlegungsrichtlinie räumt Anbietern 120 Tage Zeit ein, um einen Patch bereitzustellen, bevor Details veröffentlicht werden, und die Liste der anstehenden Sicherheitshinweise gibt für die fünf Kernel-Meldungen den 18. Februar 2027 als Frist an.

Der ConnMan-Bericht erschien zuerst am 20. Oktober um 00:17 Uhr UTC auf der öffentlichen ConnMan-Mailingliste. Auf der ZDI-eigenen Mailingliste ist als Datum der 19. Oktober angegeben, da der Bericht zu diesem Zeitpunkt nach US-Zeit versendet wurde. Die fünf Kernel-Meldungen, darunter ZDI-CAN-33367, folgten am Abend des 21. Oktober (UTC) und wurden an das Kernel-Sicherheitsteam sowie an die Mailinglisten LKML, netdev, linux-cifs, dri-devel und linux-nvme weitergeleitet. Greg Kroah-Hartman und andere Betreuer antworteten, dass die Meldungen nun öffentlich seien und ohne Patches eingegangen seien. Drei der sechs Berichte enthalten eine ausführliche Beschreibung und den vollständigen PoC-Quellcode. Bei zwei Kernel-Berichten ist außer dem Titel nichts öffentlich zugänglich, und der letzte ist gar kein Kernel-Fehler.

Seltsamerweise ist der Fehler mit der niedrigsten Kernel-Bewertung in der Liste genau der, auf den dieser Beitrag am ausführlichsten eingeht. Eine CVSS-Basisbewertung beschreibt die Schwachstelle an sich. Sie gibt keinen Aufschluss darüber, ob bereits funktionierender Exploit-Code öffentlich zugänglich ist – was bei ZDI-CAN-33367 der Fall ist. Auf Hosts, auf denen die Voraussetzungen für den Exploit gegeben sind, ist dies wichtiger als ein oder zwei Punkte in der Bewertung.

Auch für keine dieser Schwachstellen gibt es bislang eine CVE-Nummer. Das klingt zwar nach Papierkram, aber viele Scanner und Patch-Dashboards stützen sich ausschließlich auf CVE-IDs, sodass diese Berichte dort vorerst möglicherweise gar nicht angezeigt werden. Sie sollten daher Ihre üblichen Tools durch manuelle Überprüfungen und Hersteller-Updates ergänzen, bis entsprechende IDs vorliegen.

skb_zerocopy() Es überträgt Paketdaten zwischen Socket-Puffern, indem es Verweise auf dieselben Speicherseiten übergibt, anstatt Bytes zu kopieren. Das ist hervorragend für den Durchsatz. Es ist auch genau die Art von Abkürzung, die immer wieder bei Fehlern im Seiten-Cache auftaucht, bei denen ein Verweis auf eine Seite, die zu einer Datei gehört, an einer Stelle landet, an der darauf geschrieben werden kann.

Dirty Pipe hat dies im Jahr 2022 über Pipes geschafft. Copy Fail tat dies im April 2026 über den AF_ALG-Krypto-Socket. Im Mai gelang dies Dirty Frag (CVE-2026-43284) über ESP, die IPsec-Schicht, die Pakete direkt entschlüsselte, selbst wenn deren Seiten zu einer Datei gehörten. ZDI-CAN-33367 ist eine Fortsetzung des zuletzt genannten Falls.

Mit dem „Dirty Frag“-Fix wurde eine Schutzmaßnahme eingeführt. Wenn Paketdaten aus Seiten stammen, die nicht im privaten Besitz des Kernels sind, werden sie mit einem Flag versehen, das SKBFL_SHARED_FRAG, und ESP überprüft dieses Flag und erstellt vor der Entschlüsselung eine private Kopie. skb_zerocopy() übergibt dieselben Seiten an einen neuen Puffer, überträgt das Flag jedoch nicht. Die Schutzfunktion wird nie ausgelöst, ESP entschlüsselt an Ort und Stelle, und der Schreibvorgang landet im Seitencache einer Datei, auf die der Angreifer nur Lesezugriff hat. Der zugrunde liegende Fehler geht auf den Befehl „commit“ zurück af2806f8f90a, in dem vorgestellt wurde skb_zerocopy() im Kernel 3.14.

Das hat eine unangenehme Folge. AlmaLinux 8, 9 und 10 enthalten alle den „Dirty Frag“-Fix, was TuxCare in den Änderungsprotokollen des AlmaLinux-Kernels bestätigt hat, und sind dennoch anfällig. Ein Patch-Dashboard, in dem CVE-2026-43284 als geschlossen angezeigt wird, sagt nichts über diesen Fehler aus.

Genau wie bei „Dirty Pipe“ handelt es sich hierbei um einen reinen Schreibvorgang in den Seiten-Cache. Prozesse, die die Datei anschließend lesen oder ausführen, erhalten die vom Angreifer veränderte Version, und bei „Dirty Pipe“ und „Copy Fail“ wurden diese Änderungen nie in die Datei auf der Festplatte übernommen, was die forensische Untersuchung erschwerte. Richten Sie den Angriff auf eine Setuid-Binärdatei oder /etc/passwd Und Root-Rechte sind nur einen kleinen Schritt entfernt. Der Exploit benötigt weder besondere Berechtigungen noch ein KASLR-Leck, um dorthin zu gelangen.

Der veröffentlichte PoC hat eine bestimmte „Einkaufsliste“. Er benötigt Namespaces für nicht privilegierte Benutzer, über die ein nicht privilegierter Prozess üblicherweise Netzwerkadministratorrechte innerhalb seiner eigenen Sandbox erlangt. Außerdem stützt er sich auf Module, die bei Bedarf automatisch geladen werden: nfnetlink_queue, nft_queue, nlmon, cls_u32, act_pedit, act_mirred und esp4, sowie die Kryptomodule hinter einer nicht-AEAD-konformen ESP-Verschlüsselung. Der 6.1-Kernel von Debian 12 benötigt einen etwas anderen Weg, um Dateiseiten in ein Paket zu übertragen, aber der Exploit funktioniert auch dort. Diese Liste beschreibt den öffentlich bekannten Exploit, nicht jeden möglichen Weg zum Fehler, aber sie ermöglicht die Behebung des Problems, worauf weiter unten näher eingegangen wird.

Der Netdev-Betreuer Eric Dumazet antwortete auf den Bericht, dass eine andere Quelle denselben Fehler bereits eine Woche zuvor zusammen mit einem Patch gemeldet habe und dass die Korrektur bald verfügbar sein werde. Am 22. Oktober wurde dieser Patch auf Netdev veröffentlicht. Es handelt sich um eine einzeilige Änderung, die dafür sorgt, dass skb_zerocopy() das „shared-page“-Flag übernimmt, und der Patch wurde an das Stable-Team weitergeleitet.  Er wurde inzwischen als Commit `79dc34beb1fd` in den Networking-Tree aufgenommen, hat aber noch nicht den Mainline-Zweig erreicht. So oder so sagt eine Korrektur im Tree eines Betreuers nichts darüber aus, wann die korrigierten Kernel auf Ihren Hosts verfügbar sein werden. Eine Upstream-Korrektur muss erst in einen Distributionskernel integriert werden, dann in ein Paket, und schließlich muss auf jedem betroffenen Server ein Neustart oder ein Patch ohne Neustart durchgeführt werden – und der PoC befindet sich bereits in einem öffentlichen Archiv.

TuxCare hat den öffentlichen PoC für jede der unten aufgeführten Zielsysteme neu erstellt und ausgeführt. „Root verified“ bedeutet, dass der Vorgang mit einer Shell mit der UID 0 abgeschlossen wurde.

Die beiden älteren Versionen sind aus unterschiedlichen Gründen sicher. Der 2.6.32-Kernel von CentOS 6 stammt aus einer Zeit vor skb_zerocopy() vollständig, sodass es nichts zu missbrauchen gibt. Der 3.10-Kernel von CentOS 7 verfügt zwar darüber, doch sein ESP-Code erstellt vor der Entschlüsselung stets eine private Kopie nichtlinearer Pakete. Die In-Place-Abkürzung wurde im Upstream in Version 4.11 eingeführt und hat es nie in EL7 geschafft; außerdem sind nicht privilegierte Benutzernamensräume dort ohnehin standardmäßig deaktiviert.

Noch nicht getestet wurden Ubuntu 22.04 und eine Handvoll separater Kernel-Varianten, darunter EL- und ELS-Kernel, AlmaLinux-ESU- und FIPS-Kernel, Oracle UEK-, Cloud- und HWE-Kernel sowie der CloudLinux-7-Kernel. Auch CloudLinux 8 wurde noch nicht getestet, doch dessen Kernel enthält alle Module, die der öffentlich bekannte Exploit benötigt. Die korrigierten CloudLinux-7h- und 8-Kernel (4.18.0-553.177.1.lve.1) befinden sich in der Beta-Phase. Behandeln Sie alle als potenziell betroffen, bis sie überprüft wurden.

Ubuntu 24.04 und spätere Versionen wenden AppArmor-Einschränkungen auf nicht privilegierte Benutzernamensräume an, die durch kernel.apparmor_restrict_unprivileged_userns. Das hat diesen Exploit nicht verhindert. Der PoC umgeht diese Sicherheitsmaßnahme, indem er über das AppArmor-Profil eines Container-Launcher-Pakets gestartet wird, das das Erstellen von Benutzer-Namespaces zulässt. Betrachten Sie dies nicht als Abhilfemaßnahme.

ZDI bewertet beide ksmbd-Berichte mit 9,0 und stuft sie als Fehler ein, die die Ausführung von Code aus der Ferne ermöglichen – weshalb sie auch in die Schlagzeilen gerieten. Die öffentlich zugänglichen PoCs demonstrieren eher die Offenlegung von Kernel-Speicherinhalten und Systemabstürze als die Ausführung von Code. Dies sind an sich bereits echte Sicherheitsprobleme, und die veröffentlichten Ergebnisse zeigen nicht das volle Ausmaß dessen, was ein Angreifer tun könnte. ZDI nennt außerdem einen Schreibpfad außerhalb des zulässigen Bereichs für ZDI-CAN-33774, der in den öffentlich zugänglichen Unterlagen nicht aufgeführt ist.

Was den Schaden begrenzt, ist die Anfälligkeit. Beide Sicherheitslücken befinden sich in ksmbd, dem in den Kernel integrierten SMB-Server. Dieser ist unabhängig von Samba, dem SMB-Server im Userspace, den die meisten Linux-Dateiserver ausführen, und Hosts, die Dateien ausschließlich über Samba freigeben, sind von diesen Sicherheitslücken nicht betroffen.

AlmaLinux sowie CloudLinux 9 und 10 kompilieren ksmbd überhaupt nicht. Debian und Ubuntu kompilieren es zwar, aber nur als optionale Komponente. Es läuft erst, nachdem ein Administrator es installiert hat. ksmbd-tools, das standardmäßig nicht vorhanden ist, und startet das ksmbd Dienst. ZDI-CAN-33549 fügt weitere Bedingungen hinzu. Es erfordert SMB Direct über ein RDMA-Netzwerkgerät und eine beschreibbare Freigabe, auf die über einen Login- oder Gastzugang zugegriffen werden kann. Ubuntu integriert SMB Direct, Debian hingegen nicht, und RDMA-Hardware ist auf Hosting-Servern selten anzutreffen.

Falls Sie ksmbd ausführen, sollten Sie die Sicherheitslücke ZDI-CAN-33774 ernst nehmen. Sie ist bereits vor der Anmeldung über das Netzwerk erreichbar, führt zu einem Speicherleck von jeweils 28 Byte aus dem Kernel-Heap und kann den Host zum Absturz bringen. ksmbd-Betreuer Namjae Jeon antwortete dass es in seinem Baum bereits als commit 68f410faedaf, das noch nicht in den Hauptzweig übernommen wurde. Wenn systemctl is-active ksmbd zeigt „inaktiv“ an und lsmod ist nicht aufgeführt ksmbd, das ist ein gutes Anzeichen dafür, dass der Server nicht läuft, aber vergewissern Sie sich, dass kein anderes Programm auf dem Host ihn gestartet hat, bevor Sie diese Möglichkeit ausschließen. Wenn er aktiv ist und nichts von der Freigabe abhängt, beenden Sie ihn mit systemctl disable --now ksmbd. Falls die Freigabe benötigt wird, sollten Sie sie von nicht vertrauenswürdigen Netzwerken fernhalten, bis korrigierte Kernel verfügbar sind.

Der Rest des Stapels

ZDI-CAN-34068 ist ein Schreibzugriff außerhalb des zulässigen Bereichs in „vmwgfx“, dem Treiber für die virtuelle GPU von VMware, der als lokale Privilegienausweitung eingestuft wird. ZDI-CAN-34076 ist ein Speicherleck durch nicht initialisierten Speicher in „nvmet“, dem NVMe-over-Fabrics-Ziel. Beide sind bislang nur als Titel öffentlich bekannt. Da keine technischen Details vorliegen, gibt es nichts Konkretes zu überprüfen oder abzusichern, sodass keine Maßnahmen geplant sind, bis weitere Informationen bekannt werden.

ZDI-CAN-32005 betrifft ConnMan, einen Netzwerkmanager im Userspace. Da es sich nicht um einen Kernel-Fehler handelt, fällt dieser Fehler nicht in den Bereich der von KernelCare bereitgestellten Patches. Wenn Sie ConnMan einsetzen, achten Sie bitte über Ihre üblichen Paketkanäle auf Updates.

Keine der beiden unten aufgeführten Abhilfemaßnahmen wurde bisher intern anhand des PoC validiert. Testen Sie jede davon zunächst auf einem Staging-Host, um herauszufinden, welche Komponenten davon abhängig sind, und betrachten Sie keine der beiden als Ersatz für eine echte Lösung.

Die wichtigste Option ist die Deaktivierung der Namespaces für Benutzer ohne Sonderrechte. Die Einstellung user.max_user_namespaces zu 0 Verhindert die Erstellung neuer Benutzernamensräume, was den öffentlichen PoC blockieren sollte, da dieser auf der Erstellung eines solchen beruht. Im Gegensatz zur AppArmor-Einschränkung von Ubuntu handelt es sich hierbei um eine feste Kernel-Beschränkung, die kein AppArmor-Profil umgehen kann:

echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-zdi-33367.conf
sysctl --system

Bereits vorhandene Namespaces bleiben bestehen, sodass alles, was bereits in einem solchen Namespace läuft, weiterläuft. Das hat allerdings auch seinen Preis. Rootless-Container, Flatpak-Apps und einige Browser-Sandboxen sind auf Benutzer-Namespaces angewiesen und können dadurch nicht mehr funktionieren.

Die schlankere Variante deaktiviert zwei der seltener verwendeten Module, auf die sich der öffentliche PoC stützt, nlmon und act_pedit, das über den normalen Modulmechanismus geladen wird:

printf 'install nlmon /bin/false\ninstall act_pedit /bin/false\n' > /etc/modprobe.d/zdi-33367.conf
lsmod | grep -E '^(nlmon|act_pedit) '

Die lsmod Diese Zeile gibt lediglich an, ob eines der beiden Module derzeit geladen ist. Falls eines davon angezeigt wird, wird es durch die neue Regel nicht entladen. Vergewissern Sie sich, dass nichts davon abhängt, und entladen Sie das Modul dann mit modprobe -roder einen Neustart planen. Ein leeres Ergebnis ist jedoch kein Beweis dafür, dass der Block vorhanden ist. Führen Sie modprobe -n -v nlmon und modprobe -n -v act_pedit, und stellen Sie sicher, dass beide das install /bin/false Zeile. Das bestätigt die Modulkonfiguration, nicht jedoch, dass der Exploit gestoppt wurde. Nur wenige Server verwenden nlmon oder die pedit Handlung in tc, aber überprüfen Sie es, bevor Sie Vermutungen anstellen. Das Blockieren dieser beiden führt möglicherweise auch nicht zu allen Ursachen des Fehlers. Bekannt ist lediglich, dass der öffentlich zugängliche PoC sie benötigt. Der PoC benötigt esp4 ebenfalls; wenn also ein Host kein IPsec verwendet und du esp4 Für „Dirty Frag“ vom Mai: Überprüfe, ob der Block noch an seinem Platz ist.

Das Deaktivieren von Benutzer-Namespaces ist die wichtigste Option; beginnen Sie also damit auf jedem Host, der ohne diese auskommt. Prüfen Sie zunächst, was auf dem Host läuft. Auf Web-, E-Mail-, Datenbank- und Shared-Hosting-Servern ist dies in der Regel praktikabel, solange dort keine rootlosen Container oder Sandboxing-Umgebungen zum Einsatz kommen. Auf CI-Runner, Build-Hosts und Entwickler-Workstations, die auf Benutzer-Namespaces angewiesen sind, stellt das Blockieren der beiden Module eine weniger störende Ausweichlösung dar, kann jedoch andere Wege zum Fehler offen lassen. Stellen Sie diese Hosts an die erste Stelle, sobald ein Patch ohne Neustart verfügbar ist.

Einen Server in weniger als einer Minute überprüfen

Drei Befehle beantworten die meisten Fragen:

sysctl user.max_user_namespaces
systemctl is-active ksmbd
lsmod | grep -E '^(ksmbd|nlmon|act_pedit) '

A 0 Da von Anfang an neue Benutzernamensräume deaktiviert sind, sollte dies den Weg für den öffentlich bekannten Exploit versperren. inactive Die zweite Zeile deutet darauf hin, dass ksmbd nicht läuft, und die dritte Zeile bestätigt, ob die ksmbd Das Modul oder eines der beiden blockierbaren Module ist derzeit geladen. Unter Ubuntu 24.04 und höher sollte man sich davon nicht zu viel machen. sysctl kernel.apparmor_restrict_unprivileged_userns. Der PoC hat diese Einschränkung im Test umgangen. Dies sind nur erste Anhaltspunkte, kein vollständiger Sicherheitstest. Für eine Flotte sollten Sie dieselben Befehlszeilen über das Tool ausführen, das bereits Ihre Ad-hoc-Befehle verarbeitet – sei es Ansible, Salt oder einfach SSH in einer Schleife.

Der rebootless-Patch von KernelCare für ZDI-CAN-33367 ist für EL10- und EL9-Kernel unter AlmaLinux, CloudLinux, RHEL, Oracle Linux und Rocky Linux verfügbar. Er basiert auf dem Upstream-Fix-Kandidaten, und TuxCare hat bestätigt, dass er den öffentlich bekannten Exploit stoppt. Der EL10-Patch ist sowohl im Produktions- als auch im ePortal-Feed enthalten. Der EL9-Patch befindet sich im Produktions-Feed, ist jedoch noch nicht im ePortal verfügbar. Der EL8-Patch steht zur Veröffentlichung bereit, und die Arbeiten für Debian und Ubuntu sind im Gange, ein Termin steht jedoch noch nicht fest. EL6- und EL7-Kernel sind nicht anfällig, daher wird es für diesen Fehler keinen Patch ohne Neustart geben.

Auf EL9 und EL10 erhalten Hosts mit automatischen KernelCare-Updates den Patch gemäß ihrem normalen Zeitplan; alternativ können Sie ihn sofort mit dem Befehl „kcarectl –update“ abrufen. Ein Neustart ist nicht erforderlich, was hier wichtiger ist als sonst, da der oben genannte Modulblock unter Umständen einen Neustart erfordern kann. Da noch keine CVE-IDs zugewiesen wurden, hat der TuxCare CVE Tracker heute noch keine Informationen zu diesen Meldungen. Sobald IDs vorliegen, wird dort der Status der distributionsspezifischen Patches ohne Neustart angezeigt.

Holen Sie sich KernelCare Enterprise noch heute →

Warum eine solche Indiskretion die Lage grundlegend verändert

Die koordinierte Offenlegung dient dazu, den Verteidigern einen Vorsprung zu verschaffen, und diese Woche betrug dieser Vorsprung null.

Im Rahmen einer koordinierten Offenlegung haben Entwickler und Distributoren in der Regel Zeit, Korrekturen vorzubereiten, bevor technische Details oder Exploit-Code veröffentlicht werden. Hier war die Reihenfolge umgekehrt: Erst der funktionierende Exploit, dann die Korrektur. Genau diese Lücke zwischen der Veröffentlichung des Exploits und dem gepatchten Host versucht jeder Patching-Prozess so kurz wie möglich zu halten – und im Fall von ZDI-CAN-33367 entstand sie, bevor irgendjemand reagieren konnte.

Die Korrektur im Upstream-Zweig steht kurz bevor und ist bereits im Netzwerk-Zweig enthalten. Jemand anderes hatte diesen Fehler bereits eine Woche zuvor entdeckt und einen Patch eingereicht – das zeigt, wie viele Leute gerade denselben Kernel-Code durchforsten. Rechnet mit weiteren solchen Überschneidungen und weiteren Fehlern, die an die Öffentlichkeit gelangen, bevor ein stabiler Kernel die Korrektur enthält.

Überprüfen Sie also noch heute die Benutzer-Namespaces und deaktivieren Sie sie überall dort, wo sie nicht benötigt werden. Finden Sie heraus, ob jemand ksmbd aktiviert und dann vergessen hat. Achten Sie anschließend darauf, dass dieser Fix in die Kernel Ihrer Distribution einfließt, und überlegen Sie, wie schnell Sie ihn auf jeden exponierten Host aufbringen können – entweder per Patch ohne Neustart oder durch einen Neustart, je nachdem, was Ihre Infrastruktur tatsächlich zulässt.

Holen Sie sich KernelCare Enterprise noch heute →

So verlief die Woche

Quellen

Die Hauptquellen für diesen Beitrag sind die ursprünglichen ZDI-Berichte und die Antworten der Betreuer in den öffentlichen Mailinglisten, darunter der Bericht ZDI-CAN-33367, die Antwort von Eric Dumazet, der skb_zerocopy-Patch, der Thread ZDI-CAN-33774, der Fix-Commit für ksmbd und der ConnMan-Bericht sowie die Liste der anstehenden Sicherheitshinweise von ZDI, die Berichterstattung von Phoronix, der Leitfaden des Kernels zur Meldung von Sicherheitsfehlern, die Offenlegungsrichtlinie von ZDI, die ksmbd-Dokumentation des Kernels, Max Kellermanns Artikel zu „Dirty Pipe“, die Offenlegung von „Copy Fail“, der NVD-Eintrag zu „Dirty Frag“ sowie die eigenen Tests von TuxCare an den oben aufgeführten Distributionen.