Infinity Core beweist, dass auch die „ruhigen“ Teile des Kernels nicht sicher sind

Die Kurzfassung

Zur Langfassung springen ↓

Was es ist: „Infinity Core“ ist der Name, den Hyunwoo Kim (@v4bel) sechs Fehlern im Kernel-Kerncode gegeben hat, die POSIX-CPU-Timer, die Signalübermittlung, den Page-Table-Walker, Futexes, die Scheduler-Cache-Abrechnung und den SLUB-Allokator betreffen. Kim veröffentlichte die Details und den Exploit-Code am 16. Oktober 2026 auf oss-security, sobald die Sperrfrist der Linux-Distributionen abgelaufen war. Zu diesem Abschnitt springen →

Auswirkung: Fünf der sechs Schwachstellen werden durch einen öffentlich zugänglichen Proof-of-Concept belegt, der von einem gewöhnlichen Konto ohne Sonderrechte ausgeht und mit einer Root-Shell endet. Kim stuft dieselben fünf Schwachstellen zudem als „Container-Escapes“ ein. Die sechste Schwachstelle, die SLUB betrifft, führt bislang lediglich zu einem Panic des Kernels. Zu diesem Abschnitt springen →

Schweregrad: Die Bewertungen geben dies nicht ausreichend wieder. Amazon Linux stuft die Timer- und Signal-Fehler nach CVSS 3.1 mit 7,0 und den MM-Fehler mit 6,3 ein, jeweils mit lokalem Angriffsvektor und hoher Angriffskomplexität. Diese Bewertungen wurden veröffentlicht, bevor funktionierende Root-Exploits öffentlich bekannt waren. Zu diesem Abschnitt springen →

Wer ist betroffen: Ubuntu 26.04 ist am stärksten betroffen. Die Root-Exploits für die Timer-, Signal-, MM- und Futex-Sicherheitslücken wurden auf dieser Version geschrieben und getestet. 7.0.0-30-generic Kernel, und das Kernel-Team von TuxCare hat auch unter Ubuntu 26.04 bei allen vier Fällen Root-Rechte reproduziert. Der Timer-Fehler betrifft zudem die EL9- und EL10-Kernel, Debian 12 und 13 sowie Ubuntu 24.04, wo die Tests von TuxCare zwar Abstürze, aber keine Root-Rechte hervorgerufen haben – zumindest noch nicht. Die Scheduler- und SLUB-Fehler treten nur in Version 7.2 und höher auf. Zu diesem Abschnitt springen →

Status: Für alle sechs Schwachstellen liegen Upstream-Korrekturen vor, und vier der CVE-Einträge waren bereits zwischen dem 4. September und dem 6. Oktober öffentlich bekannt. Die Distributionen holen ungleichmäßig auf. Debian beispielsweise hat bereits sicherheitsaktualisierte Kernel sowohl für „Bookworm“ als auch für „Trixie“ veröffentlicht, und Red Hat hat den Futex-Fehler für RHEL 9 bereits am 1. Oktober behoben. Es liegen keine Berichte über Ausnutzungen in freier Wildbahn vor. Es handelt sich hierbei um N-Days mit öffentlichen Exploits, nicht um Zero-Days.

So gehen Sie vor: Es ist kein sysctl-Eintrag oder Modul bekannt, das deaktiviert werden müsste. Installieren Sie zunächst die korrigierten Kernel auf Ubuntu-26.04-Hosts, beginnend mit solchen, auf denen Code von Personen ausgeführt wird, denen Sie nicht vollständig vertrauen, wie z. B. Shared-Hosting-Server, CI-Runner und Multi-Tenant-Container-Hosts. Falls Ihre Distribution bereits einen Fix bereitstellt, installieren Sie diesen und planen Sie den Neustart. Das Deaktivieren von nicht privilegierten Benutzernamensräumen hilft nicht, da keiner dieser Fehler einen solchen benötigt. So sehen Sie, welcher Kernel tatsächlich läuft:

uname -r

Vergleichen Sie dies mit den Empfehlungen Ihres Anbieters und nicht mit den Versionsnummern der Upstream-Version. Distributions-Kernel portieren Fehlerbehebungen zurück, ohne die Basisversion zu erhöhen.

Zu diesem Abschnitt springen →

Viele der Kernel-Privilegieneskalationen, die in den Nachrichten auftauchen, stammen aus denselben wenigen Bereichen: Netzwerke, Sockets, BPF, perf. Es handelt sich um Fehler, für deren Ausnutzung ein nicht privilegierter Benutzer-Namespace benötigt wird. In Leitfäden zur Systemabsicherung wird Administratoren seit Jahren vermittelt, diese Bereiche abzugrenzen, und viele Unternehmen haben genau das getan.

Infinity Core umgeht all das. Kim hat diese Bereiche bewusst ausgelassen und sich stattdessen den Code angesehen, der bei jedem Prozess ohne Weiteres ausgeführt wird, wie zum Beispiel exec(), Signalverarbeitung, mincore() und Futexes. Das Ergebnis waren vier Root-Exploits auf einer Standardinstallation von Ubuntu 26.04, ein weiterer auf Arch Linux sowie keine bekannten sysctl- oder Modul-Einstellungen, mit denen sich diese beheben lassen.

Die Korrekturen sind bereits im Upstream enthalten. Was vielen Hosts fehlt, ist ein laufender Kernel, der diese Korrekturen enthält.

Was am 16. Oktober eingetroffen ist

Kim meldete die Fehler zunächst vertraulich, bearbeitete sie über die „linux-distros“-Mailingliste und veröffentlichte sie, sobald die Sperrfrist am 16. Oktober 2026 abgelaufen war. Der Beitrag auf „oss-security“ und das InfinityCore-Repository enthalten detaillierte Beschreibungen der einzelnen Fehler sowie den Exploit-Code. Dies ist übrigens nicht Kims erster Auftritt in diesem Blog. Derselbe Forscher hatte bereits Januscape und Zapscape entdeckt, die KVM-Escape-Lücken aus diesem Jahr.

Vier der sechs hatten bereits vor dem Tag der Offenlegung öffentliche CVE-Einträge. Das Kernel CNA veröffentlichte die Futex-CVE am 4. September, die MM-CVE am 11. September und die Timer- und Signal-CVEs am 6. Oktober. Jede davon wurde unter einem der für Kernel-CVEs typischen trockenen, an Commit-Bezeichnungen angelehnten Titel veröffentlicht, der keinerlei Hinweis darauf enthielt, dass ein Root-Exploit bevorstand. Ein CVE, der wie ein Bereinigungspatch klingt, lässt sich leicht bis zum nächsten Wartungsfenster zurückstellen. Das Gleiche gilt jedoch nicht für denselben CVE, wenn ein Root-Exploit auf GitHub bereitsteht.

Ein Teil wird noch zurückgehalten. Kim sagt, dass der Timer-Fehler auch auf einem Samsung Galaxy S26 Ultra von einer gewöhnlichen App aus vollständige Root-Rechte gewährt, und dass dieser Exploit geheim bleibt, bis Samsung einen Patch veröffentlicht oder jemand anderes zuvor einen veröffentlicht.

Der Timer und die Signalfehler haben denselben Auslöser, und der ist etwas eigenartig. Wenn ein Thread, der nicht der Prozess-Leader ist, die Funktion exec() Und wenn der Vorgang weit genug fortgeschritten ist, tauscht der Kernel die Thread-IDs aus, sodass der aufrufende Thread die Rolle des neuen Leaders übernimmt. Beide Fehler liegen in der Aufräumphase rund um diesen Austausch.

CVE-2026-98260, der Timer-Fehler, erfordert einen POSIX-CPU-Timer pro Thread, der für diesen Thread aktiviert ist. Wenn exec() Wenn der Vorgang nach dem ID-Austausch fehlschlägt, wird der Timer freigegeben, während sein Knoten noch in der Warteschlange einer aktiven Aufgabe steht, und die spätere Bereinigung stößt direkt auf diesen freigegebenen Knoten. Ein klassischer „Use-after-free“-Fehler. Der öffentlich bekannte Exploit führt unter Ubuntu 26.04 zu einer Root-Shell, und der Fix, acb03d388181, verschiebt die Bereinigung des Timers auf unmittelbar danach de_thread() damit nichts in der Schwebe bleibt, wenn exec() Kautionen.

CVE-2026-98256, der „Signal-Bug“, ist ein Wettlauf um denselben Zeitpunkt. Ein Pfad leert die ausstehenden Signale des sterbenden Leaders, ohne eine Sperre zu setzen, während ein anderer dem vertauschten PID folgt und eine sigqueue Eintrag in die Warteschlange des neuen Leiters. Werden die Verweise manipuliert, überdauert ein Eintrag das Objekt, zu dem er gehört. Kims Exploit nutzt diesen übrig gebliebenen Eintrag als Orakel, um festzustellen, wann der freigegebene Speicher wiederverwendet wurde, und missbraucht anschließend den Pfad, über den das manipulierte Signal aus der Warteschlange entfernt wird, um eine Root-Shell zu erlangen. Die Korrektur besteht darin, d2710c8d938a.

Programme schlagen fehl exec() Den ganzen Tag lang. Ein fehlerhafter Pfad, ein fehlender Interpreter, ein Signal zum falschen Zeitpunkt. Keiner der beiden Fehler tritt jedoch bei jedem dieser Fälle auf. Der Timer-Fehler setzt voraus, dass der Fehler erst nach dem Austausch der Thread-ID auftritt, und der Signal-Fehler erfordert, dass ein Angreifer bei genau diesem Austausch das Wettrennen gewinnt. Von außen betrachtet sieht ein solcher Versuch immer noch wie gewöhnliche Prozessaktivität aus, weshalb es außer durch das Einpatchen keine saubere Möglichkeit gibt, ihn herauszufiltern.

Die Schwachstelle CVE-2026-89754 befindet sich im Page-Table-Walker. Bei einem Race-Condition-Szenario mit madvise(MADV_DONTNEED), ein Wiederholungsflag aus einer tieferen Ebene dringt nach oben durch, und mincore() durchläuft denselben Bereich zweimal. Zu diesem Zeitpunkt ist der Ausgabecursor bereits weitergewandert, sodass der zweite Durchlauf über einen temporären Puffer hinausschreibt, der genau eine Seite lang ist. Kims Exploit speichert einen „Credential Slab“ auf der nächsten physischen Seite und nutzt den Überlauf, um die UID- und GID-Felder eines struct cred. Viel direkter als das geht es bei Kernel-LPE kaum. Die Lösung lautet aedf2efd1897.

CVE-2026-80775, der „Futex“-Fehler, erfordert, dass sich zwei Tasks eine mm_struct, das verschachtelt war vfork() tritt ein, sobald das mittlere Kind zerstört wird. Beide versuchen, den ersten Referenzzähler für den privaten Futex-Hash zu setzen. Da nur ein Speichervorgang erfolgreich ist, werden die Referenzen auf den anderen Zähler nicht mehr nachverfolgt, und ein noch verwendeter Hash wird freigegeben. Der Exploit gewinnt ihn mithilfe eines Pipe-Rings zurück und überschreibt den Seiten-Cache von /usr/bin/passwd. Dadurch wird die vom Kernel für die Datei bereitgestellte Ausgabe geändert, ohne dass die Änderung auf die Festplatte geschrieben wird. Die Manipulation ist also möglicherweise nicht mehr vorhanden, sobald die zwischengespeicherte Seite gelöscht wird oder der Host neu gestartet wird. Viel Glück bei der anschließenden Untersuchung. Die Lösung lautet bde023808364.

Die letzten beiden sind für die meisten Flotten weniger relevant. CVE-2026-98385 ist ein „Use-after-free“-Fehler in der Cache-Verwaltung des Schedulers, der CONFIG_SCHED_CACHE=y Im Build war die Scheduler-Cache-Abrechnung zur Laufzeit aktiviert, und es lag eine CPU-Topologie mit mehr als einem Last-Level-Cache vor. Der Exploit erlangte Root-Rechte unter Arch Linux mit einem 7.2.4-Kernel. CVE-2026-97941 ist ein ABA-Race-Condition beim Nachfüllen von SLUB-Objekten, der eine Teileliste beschädigt. Der öffentlich bekannte Trigger löst lediglich einen Panic des Kernels aus, und es wurde noch kein Root-Exploit dafür veröffentlicht. Beide Schwachstellen befinden sich in Code, der erstmals in Version 7.2 auftauchte, sodass kein von KernelCare unterstützter Distributionskernel eine davon enthält.

Zum Zeitpunkt der Erstellung dieses Artikels standen die NVD-Bewertungen für die Timer- und Signal-Fehler noch aus. Amazon Linux hat Bewertungen für drei davon veröffentlicht und den Timer- und Signal-Fehlern mit dem Vektor die Note 7,0 zugewiesen. AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, und 6.3 wegen des MM-Fehlers.

Die AC:H Dieser Teil verdient besondere Beachtung. Bei den meisten handelt es sich um Wettläufe, und „es ist ein Wettlauf“ war früher ein triftiger Grund, etwas in der Warteschlange nach hinten zu verschieben. Ein öffentlich bekannter Exploit, der die harte Arbeit bereits hinter sich hat und das Rennen gewonnen hat, verändert die Lage. Eine Schwachstelle der Stufe 7,0 mit einer funktionierenden Root-Shell auf einem Host, auf dem nicht vertrauenswürdige Benutzer Code ausführen können, verdient einen Platz ganz oben auf der Liste. Das sagt mehr über die Dringlichkeit aus als die Zahl allein.

Wer sollte sich zuerst Sorgen machen?

Jeder dieser Prozesse beginnt mit einem einfachen lokalen Konto ohne Sonderrechte, ohne Benutzernamensraum und ohne Zugriff auf spezielle Geräte. Die eigentliche Frage lautet also: Wer kann auf Ihren Hosts Code ausführen, über den Sie keine vollständige Kontrolle haben?

Shared-Hosting-Server mit SSH- oder Control-Panel-Shells für Kunden sind die naheliegende Antwort. CI-Runner, die beliebige Pull-Requests erstellen, sind eine weitere. Ebenso wie jeder Host, auf dem Container für Mandanten laufen, die einander nicht vertrauen. Kim stuft alle fünf Root-Bugs als Container-Escapes ein, und das passt. Jeder Container nutzt den Host-Kernel gemeinsam, und die betroffenen Systemaufrufe sind alltägliche Funktionen, die von Container-Workloads ständig genutzt werden. Sofern nicht zufällig ein Seccomp-Profil oder eine LSM-Richtlinie genau diesen Pfad blockiert, sollten Sie sich nicht darauf verlassen, dass die Containergrenze Sie schützt.

Ein Datenbank-Server mit nur einem Verwendungszweck, auf dem drei Administratoren arbeiten, ist eine andere Sache. Auch hier ist die Fehlerbehebung erforderlich. Es hat nur nicht oberste Priorität.

Ist „Infinity Core“ ein Zero-Day-Angriff?

Nein. Alle Korrekturen wurden bereits im Upstream-Bereich vorgenommen, bevor die Exploits öffentlich bekannt wurden, und der früheste CVE-Eintrag datiert etwa sechs Wochen vor der Offenlegung. Es gibt keine Berichte über Ausnutzung in der Praxis. Hier handelt es sich um „N-Days“ mit öffentlichen Exploits, was die Verteidiger in eine noch schlechtere Lage bringen kann. Der Zeitdruck hängt nun davon ab, wie schnell die Distributionen die korrigierten Kernel bereitstellen und wie schnell die Administratoren tatsächlich darauf umsteigen.

Übersicht über die von KernelCare unterstützten Distributionen zum Stand vom 19. Oktober 2026, basierend auf einer eigenen Analyse von TuxCare und unabhängig vom Kernel-Status der einzelnen Anbieter:

„Crash so far“ muss mit einer Einschränkung versehen werden. Ein funktionierender Root-Exploit für eine Kernel-Version ist ein großer Vorsprung auf dem Weg zur nächsten, auch wenn die Anpassung noch erheblichen Aufwand erfordert. Ein Root-Zugriff wurde bei diesen Distributionen zwar noch nicht nachgewiesen, doch die lokale Rechteausweitung stellt dort ein glaubwürdiges Risiko dar, und die Priorität bei der Behebung sollte dies widerspiegeln.

Wie eingangs erwähnt, sagt eine Versionsangabe allein hier noch nichts aus. Nur eine Herstellerempfehlung oder ein verifizierter Patch für genau diesen Kernel ist ausschlaggebend.

Holen Sie sich KernelCare noch heute →

Warum es keine schnelle Abhilfe gibt

Bei vielen der jüngsten Kernel-LPEs reichte eine einzige Zeile als Notlösung aus: Ein Modul auf die Blacklist setzen, einen sysctl-Wert umschalten, nicht privilegierte Benutzernamensräume deaktivieren. Diesmal funktioniert nichts davon. Kim hat Fehler, die einen Benutzernamensraum benötigen, absichtlich ausgelassen, und der Rest befindet sich in exec(), Signalverarbeitung, mincore() sowie Futex-Code, den kein laufendes System entladen oder deaktivieren kann. TuxCare hat noch keine zuverlässige Abhilfe gefunden. Die üblichen Maßnahmen, wie das Deaktivieren von Namespaces für Benutzer ohne Sonderrechte oder das Hinzufügen eines Moduls zur Blacklist, wirken sich nicht auf die anfälligen Codepfade aus, und für jeden einzelnen Fehler wurde noch keine eigene Abhilfe verifiziert.

Damit bleiben die weniger zufriedenstellenden Optionen. Reduzieren Sie die Anzahl der Benutzer, die auf exponierten Hosts über eine lokale Shell verfügen, bis diese gepatcht sind. Verlegen Sie Mandanten, die einander wirklich nicht vertrauen, in separate VMs statt in Container auf einem gemeinsam genutzten Kernel. Und behalten Sie das Kernel-Protokoll im Auge. Bei einigen dieser Vorgänge handelt es sich um Wettläufe, und ein fehlgeschlagener Versuch kann zu einem „Oops“ oder einer Panik im Kernel führen, anstatt stillschweigend zu scheitern – auch wenn ein sauberes Protokoll nicht beweist, dass nichts passiert ist:

journalctl -k | grep -iE 'BUG:|Oops|general protection'

Ein unerklärlicher Fehler, der diese Woche auf einem Mehrbenutzer-Host aufgetreten ist, verdient eine genauere Betrachtung.

Die dauerhafte Lösung ist ein Kernel, der die Upstream-Patches enthält – entweder aus Ihrer Distribution oder aus Ihrem eigenen Build. Bei der Installation des Pakets wird der bereits im Speicher laufende Kernel nicht verändert, sodass sich nichts ändert, bis der Host mit dem neuen Kernel hochfährt. Überprüfen Sie, was tatsächlich läuft:

uname -r

Ein Host, auf dem ein korrigierter Kernel installiert wurde, der aber nie neu gestartet wurde, läuft weiterhin mit der anfälligen Version. Shared-Hosting-Server und CI-Pools sind in der Regel die schlimmsten Fälle, da ein Neustart bedeutet, dass Kunden gewarnt oder laufende Jobs abgebrochen werden müssen.

Sobald sie für Ihren Kernel freigegeben sind, wenden die „rebootless patches“ von KernelCare die Korrektur auf den laufenden Kernel an, ohne dass ein Neustart erforderlich ist. Sind automatische Updates aktiviert, wird ein Patch bei der nächsten geplanten Überprüfung übernommen, sobald er im Feed für den laufenden Kernel verfügbar ist, und kcarectl --update fordert diese bei Bedarf an. So überprüfen Sie die Abdeckung für die vier Fehler, die von unterstützten Distributions-Kerneln betroffen sind:

kcarectl --patch-info | grep -E 'CVE-2026-(98260|98256|89754|80775)'

Die CVEs zum Scheduler und zu SLUB wurden bewusst aus diesem Muster ausgeklammert, da kein unterstützter Distributionskernel diese enthält. Stand 19. Oktober 2026 ist der einzige veröffentlichte Infinity-Core-Patch der Futex-Fix für einen AlmaLinux-9-Kernel-Stream. Bislang wurde noch kein Patch für den Timer-Fehler in irgendeiner Distribution oder für die vier Fehler in Ubuntu 26.04 veröffentlicht. In diesem Beitrag finden Sie in den kommenden Tagen aktuelle Informationen. Sobald ein Patch Ihren Stream erreicht, vergewissern Sie sich, dass KernelCare ihn tatsächlich auf den laufenden Kernel angewendet hat, und beschränken Sie den Zugriff streng, bis die Abdeckung der relevanten CVEs überprüft wurde.

Warum Infinity Core so wichtig ist

Die Abstrahlung hat ihre Grenzen. Systemadministratoren sind mittlerweile sehr gut darin, nicht benötigte Angriffsflächen zu beseitigen, und diese Arbeit zahlt sich aus. Aber niemand kann exec(). Kim hat sich auf die Suche in Subsystemen mit einer unauffälligen Sicherheitsbilanz begeben und sechs Fehler gefunden. Ausgereifter, intensiv genutzter Code ist nicht gleichbedeutend mit sicherem Code, und eine Absicherung allein reicht nicht aus, um diese Lücke zu schließen.

Wenn Sie Ubuntu 26.04 mit nicht vertrauenswürdigen lokalen Benutzern betreiben, ist dies die erste Patch-Aufgabe dieser Woche. Auf EL-, Debian- und Ubuntu 24.04-Hosts sollten Sie dem Timer-Fehler höchste Priorität einräumen, auch wenn im Testbetrieb bisher nur Abstürze aufgetreten sind, da der öffentlich bekannte Ubuntu-Exploit einen Root-Zugriff als nächsten Schritt wahrscheinlich macht. Und wenn ein Neustart bedeutet, dass ein CI-Pool leergeräumt oder E-Mails an einige hundert Hosting-Kunden versendet werden müssen, sind die rebootless Patches von KernelCare dafür gedacht, diese Fehler im laufenden Kernel zu beheben, sobald die Korrekturen vorliegen – ganz ohne Wartungsfenster.

Holen Sie sich KernelCare noch heute →

Zeitleiste

Referenzen

Kims „Infinity Core“-Beitrag auf oss-security (16. Oktober 2026), das InfinityCore-Repository mit Exploit-Code und Beschreibungen der einzelnen Fehler, die CVE-Einträge für CVE-2026-98260, CVE-2026-98256, CVE-2026-89754, CVE-2026-80775, CVE-2026-98385 und CVE-2026-97941, der vollständige Satz der im Repository von Kim aufgeführten Upstream-Fix-Commits, einschließlich des Timer-Fixes acb03d388181 und des Futex-Fixes bde023808364, der Eintrag im Debian-Sicherheits-Tracker für CVE-2026-98260, Red Hats RHSA-2026:74438 sowie die Bewertung von Amazon Linux für CVE-2026-98260, CVE-2026-98256 und CVE-2026-89754.