Infinity Core: sechs Linux-Kernel-Lücken mit öffentlichen Exploits

Der Sicherheitsforscher Hyunwoo Kim hat am 16. Oktober 2026 auf der Mailingliste oss-security sechs Schwachstellen im Linux-Kernel offengelegt, die zusammen „Infinity Core“ heißen. Laut Kim „können sie für LPE auf Linux-Servern, Container-Ausbrüche und LPE auf Android ausgenutzt werden“. LPE, also Local Privilege Escalation, bedeutet, dass ein normaler Nutzer zu root wird. Funktionierende Exploits sind bereits öffentlich. Wer gemeinsam genutzte Linux-Rechner oder Container-Hosts betreibt, sollte seine Kernel deshalb jetzt aktualisieren.

Die sechs Infinity-Core-Schwachstellen

Der Beitrag auf oss-security nennt für jeden Fehler die CVE-ID, das Subsystem, in dem er steckt, und den Commit, der ihn behoben hat. Versionsnummern nennt er nicht. Die unten aufgeführten gepatchten Kernel-Versionen stammen von SecurityOnline, nicht aus Kims Beitrag.

Subsystem	CVE	Fehlertyp	Behoben in (laut SecurityOnline)
Timer	CVE-2026-98260	Use-after-free beim Aufräumen von POSIX-CPU-Timern	6.6.158, 6.12.112, 6.18.54, 7.2.8
Signal	CVE-2026-98256	Use-after-free in der Warteschlange ausstehender Signale	6.18.54, 7.2.8
Speicher	CVE-2026-89754	Schreibzugriff außerhalb der Grenzen im Page-Table-Walker hinter mincore()	6.18.50, 7.2.4
Futex	CVE-2026-80775	Use-after-free beim Einrichten des privaten Futex-Hashs	6.18.47, 7.1.11, 7.2.1
Scheduler	CVE-2026-98385	Use-after-free in der Cache-Buchführung des Schedulers	7.2.9
SLAB	CVE-2026-97941	Listenbeschädigung im Speicher-Allocator SLUB	7.2.7

Die meisten davon sind Use-after-free-Fehler. Der Kernel gibt ein Stück Speicher frei, nutzt es aber weiter, und ein Angreifer kann diesen Speicher mit Daten seiner Wahl neu füllen. Mehrere hängen zudem von einer Race Condition ab, bei der zwei Operationen in einem exakten Moment aufeinandertreffen. Die Timer- und Signal-Fehler etwa werden ausgelöst, wenn exec() in einem Multithread-Programm fehlschlägt oder in eine Race Condition gerät. Der Aufruf exec() ersetzt ein laufendes Programm durch ein neues.

SecurityOnline zufolge reicht der Timer-Fehler bis Linux 5.7 zurück, weshalb er auch ältere Langzeit-Kernel erreicht. Die Scheduler- und SLAB-Fehler betreffen nach Darstellung von SecurityOnline nur die Serie 7.2.

Wie ernst sie sind

Fünf der sechs kommen mit einem öffentlichen Proof-of-Concept-Exploit, der eine Root-Shell verschafft, so Kims GitHub-Repository und SecurityOnline. Der sechste, der SLAB-Fehler, bringt den Kernel bislang nur zum Absturz. „Eine LPE-Kette wurde noch nicht geschrieben“, heißt es im Repository.

Kim hat die Exploits unter Ubuntu 26.04 mit Kernel 7.0.0-30-generic und unter Arch Linux mit Kernel 7.2.4-arch1-2 getestet. Der Scheduler-Fehler ist enger begrenzt als die übrigen. Er setzt die Build-Option CONFIG_SCHED_CACHE und eine aktivierte Laufzeiteinstellung voraus, und sein Exploit geht von vier virtuellen CPUs aus.

SecurityOnline stuft vier der Fehler als High ein, mit einem höchsten CVSS-Wert von 7,8, und zwei warten noch auf eine Analyse. Angriffe in freier Wildbahn meldet die Seite nicht. Keiner der sechs steht im Known Exploited Vulnerabilities Catalog der CISA, der US-Liste von Fehlern, die bei echten Angriffen beobachtet wurden.

Die Forschung hat Netzwerk, BPF und Fehler, die User Namespaces brauchen, bewusst ausgeklammert. SecurityOnline argumentiert, dass ein gängiger Härtungsschritt, das Abschalten unprivilegierter User Namespaces oder von BPF, diese Fehler nicht blockieren würde.

Auch Android-Smartphones sind betroffen

Der Timer-Fehler funktioniert laut Kims Repository auch auf Android. Er verschafft auf einem Samsung Galaxy S26 Ultra Root-Rechte aus einer gewöhnlichen App heraus, „ohne zusätzliche Anwendungsberechtigungen“. Kim hält diesen Android-Exploit zurück. Er wird veröffentlicht, sobald Samsung seine Geräte patcht oder jemand anderes zuerst einen Exploit veröffentlicht. Ein Samsung-Advisory oder ein Patch-Datum findet sich in den Quellen nicht.

Wie die Offenlegung ablief

Kim meldete die Fehler vertraulich an linux-distros, die geschlossene Liste, auf der Linux-Anbieter Fixes vorbereiten, bevor ein Fehler öffentlich wird. Laut Kims öffentlichem Beitrag ist das mit diesen Maintainern vereinbarte Embargo abgelaufen. Die Offenlegung kam zwei Tage vor dem Release von Linux 7.3 am 18. Oktober.

Was das für Entwickler bedeutet

Installieren Sie den neuesten Kernel Ihrer Distribution und starten Sie neu. Ein Kernel-Fix bewirkt nichts, bis die Maschine mit dem neuen Kernel bootet. Distributionen portieren Fixes oft in ihre eigenen Versionsnummern zurück. Suchen Sie daher in den Sicherheitshinweisen Ihres Anbieters nach den sechs CVE-IDs, statt Versionsnummern mit der Tabelle oben zu vergleichen.

Patchen Sie die riskantesten Maschinen zuerst. Ein Container-Ausbruch lässt Code in einem Container den gesamten Host übernehmen. Damit stehen Kubernetes-Nodes, gemeinsam genutzte Build-Server und CI-Runner ganz vorn in der Reihe, besonders Runner, die Pull Requests von Fremden bauen.

Verlassen Sie sich nicht darauf, User Namespaces oder BPF als Notlösung abzuschalten. Wenn Sie Android-Testgeräte betreiben, installieren Sie Samsungs Sicherheitsupdate, sobald es erscheint, denn der Timer-Fehler funktioniert aus einer gewöhnlichen App heraus.

Auch das Muster ist bemerkenswert. Diese Fehler stecken in zentralem Kernel-Code wie Timern, Signalen und dem Speicher-Allocator, den jedes System ausführt. Die Container-Isolation stützt sich auf diesen gemeinsamen Kernel, sodass ein Kernel-Fehler eine Grenze überschreiten kann, die aus dem User Space solide wirkt.