CVE-2026-31431 (Copy Fail): Was das für eingebettete Linux-Geräte bedeutet – und was jetzt zu tun ist

Am 29. April 2026 veröffentlichte Theori CVE-2026-31431 („Copy Fail“) – eine Sicherheitslücke im Linux-Kernel, die eine Rechteausweitung ermöglicht algif_aead Krypto-Schnittstelle, die über AF_ALG-Sockets zugänglich ist. Betroffen sind gängige Linux-Distributionen, die anfällige Kernel-Builds verwenden, die 2017 eingeführt wurden.

Der Exploit erfordert lokalen Zugriff, doch aufgrund seines deterministischen Verhaltens und seiner Fähigkeit, die Dateiintegritätsüberwachung zu umgehen, ist er für eingebettete Systeme relevant – insbesondere für solche, die Container oder allgemeine Linux-Builds verwenden.

In diesem Artikel geht es darum, was den Unterschied ausmacht, wo das eigentliche Risiko für Embedded-OEMs liegt und wie man damit umgehen kann.

Kurzinfo

• Typ: Lokale Rechteausweitung (LPE)
• CVE: CVE-2026-31431 (CVSS 7,8)
• Auswirkungen: Linux-Kernel ab 2017 mit CONFIG_CRYPTO_USER_API_AEAD aktiviert
• Sicherheitslücke: Deterministisch, keine Race Condition, öffentlicher PoC verfügbar (732-Byte-Python-Skript; die Kernel-Primitive ist sprachunabhängig)
• Gültigkeitsbereich: containerübergreifend über gemeinsamen Seiten-Cache
• Behebung: Kernel-Patch im Stable-Tree und in den Backports der Hersteller verfügbar

Was „Copy Fail“ so besonders macht

Der Linux-Kernel hatte bereits in der Vergangenheit viel beachtete Sicherheitslücken, die eine Rechteausweitung ermöglichten. „Dirty Cow“ (2016) erforderte eine Race Condition und führte häufig zum Absturz von Systemen. „Dirty Pipe“ (2022) war versionsspezifisch. „Copy Fail“ ist ein Problem anderer Art.

Es ist deterministisch. Es gibt kein Wettlauf-Szenario, kein Zeitfenster und keine kernelspezifischen Offsets. Derselbe unveränderte Exploit verschafft Root-Rechte unter Ubuntu, Amazon Linux, RHEL und SUSE – und zwar auf allen getesteten gängigen Distributionen, ohne dass Timing- oder Race-Conditions erforderlich sind. Damit entfällt eine der wichtigsten natürlichen Abwehrmechanismen bei der Ausnutzung von Kernel-Schwachstellen: die Unvorhersehbarkeit.

Für herkömmliche Integritätsprüfungstools ist dies nicht erkennbar. Der Exploit verändert den Seiten-Cache im Arbeitsspeicher einer Setuid-Binärdatei, nicht die Datei auf der Festplatte. Bei der üblichen Dateiintegritätsüberwachung, die Prüfsummen auf Festplattenebene überprüft, wird nichts festgestellt. Die Binärdatei auf der Festplatte bleibt unverändert. Wenn der Kernel sie jedoch lädt, wird die manipulierte Version im Arbeitsspeicher ausgeführt – mit Root-Rechten.

Und dies geht über Containergrenzen hinaus. Der Seitencache wird von allen Prozessen auf einem Host gemeinsam genutzt, einschließlich der Container. Ein kompromittierter Container kann Binärdateien beschädigen, die für andere Container und den Host-Kernel sichtbar sind. Für Architekturen, die auf containerbasierter Isolation beruhen – einschließlich Designs mit gemischter Kritikalität, wie sie in medizinischen und industriellen Systemen zum Einsatz kommen –, stellt dies einen praktischen Fluchtweg aus dem Container dar.

Die technische Ursache

Die Sicherheitslücke befindet sich im Kernel algif_aead Kryptografiemodul. Das Problem rührt von der unsicheren Handhabung von durch den Seiten-Cache unterstützten Scatterlists bei In-Place-AEAD-Operationen her, wodurch beschreibbare Verweise auf ansonsten schreibgeschützte, durch Dateien unterstützte Seiten ermöglicht werden. Ein Optimierungs-Commit aus dem Jahr 2017 führte diese In-Place-Operationsbehandlung ein und unterlief damit eine entscheidende Sicherheitsannahme.

Der Exploit nutzt die Schwachstellen des Kernels aus AF_ALG Krypto-Schnittstelle (die es Benutzern ohne Sonderrechte ermöglicht, hardwarebeschleunigte Verschlüsselung durchzuführen) mit splice() (das Seiten aus dem Seitencache per Referenz übergibt, anstatt sie zu kopieren). Das Ergebnis ist ein kontrollierter 4-Byte-Schreibvorgang in den Seitencache einer beliebigen lesbaren Datei. Wähle dazu eine geeignete setuid-Binärdatei wie /usr/bin/su und schon hast du Root-Rechte.

AF_ALG Diese Funktionen sind in praktisch jeder gängigen Kernel-Konfiguration aktiviert. Es sind keine besonderen Berechtigungen oder zusätzlichen Module erforderlich.

Wo das Risiko real ist und wo nicht

„Copy Fail“ ist eine lokale Rechteausweitung. Der Angreifer muss bereits über lokalen Zugriff als Benutzer ohne Sonderrechte verfügen.

Bei den meisten eingebetteten Geräten – medizinischen Spezialgeräten, industriellen Steuerungen, stark gesicherten Systemen – gibt es weder ein Benutzerkonto ohne Administratorrechte noch eine interaktive Shell, und es besteht keine Möglichkeit, ein Python-Skript auszuführen, ohne zuvor eine separate Sicherheitszone zu durchbrechen. In solchen Umgebungen ist die direkte Ausnutzbarkeit gering.

Systeme, auf denen strenge SELinux- oder AppArmor-Richtlinien angewendet werden, sind möglicherweise ebenfalls weniger anfällig. Auf Android-/AOSP-Geräten mit ordnungsgemäß durchgesetztem SELinux ist die AF_ALG-Socket-Schnittstelle für nicht privilegierte Prozesse in der Regel nicht zugänglich – die Offenlegung von „Theori“ bestätigte, dass Geräte mit tiefgreifender SELinux-Integration über diesen Weg nicht betroffen sind. Dies ist für jedes eingebettete System relevant – ob auf Android-Basis oder nicht –, bei dem Richtlinien zur zwingenden Zugriffskontrolle den Zugriff auf Krypto-Schnittstellen des Kernels einschränken.

Das heißt aber nicht, dass man es ignorieren kann. Drei Szenarien sind entscheidend:

Containerbasierte Architekturen. Wenn Ihr Gerät mehrere Workloads in Containern auf einem gemeinsam genutzten Kernel ausführt – was bei medizinischen Geräten, bei denen ältere Funktionen auf moderne SoCs konsolidiert werden, immer häufiger vorkommt –, durchbricht „Copy Fail“ das Isolationsmodell. Ein kompromittierter Anwendungscontainer kann auf den Host entkommen.

In Verbindung mit einer Netzwerkschwachstelle. Ein Kopierfehler wird zu einem ernsthaften Problem, wenn er mit einer Schwachstelle zur Remote-Codeausführung kombiniert wird. Ein Angreifer, der sich über einen Fehler in der Weboberfläche, eine offen zugängliche API oder einen kompromittierten Update-Kanal zunächst Zugriff verschafft, kann sich dann sofort Root-Rechte verschaffen. Entscheidend ist die Kette der Schwachstellen.

Einhaltung gesetzlicher Vorschriften. Selbst wenn die Sicherheitslücke in Ihrer Konfiguration praktisch nicht ausnutzbar ist, entstehen durch eine öffentliche CVE mit einem funktionierenden Proof-of-Concept Dokumentations- und Bewertungspflichten gemäß den FDA-Leitlinien für die Zeit nach der Markteinführung, der EU-MDR und der Norm IEC 62443. Ihre Qualitäts- und Regulierungsteams müssen Ihr Risiko bewerten und dokumentieren. Dieser Schritt ist nicht optional.

Es geht nicht um die Distribution. Es geht um die Kernel-Konfiguration.

Es herrscht die weit verbreitete Fehlannahme, dass es sich hierbei um ein „Distributionsproblem“ handelt – dass ein Wechsel von Ubuntu zu Yocto dieses Problem beheben würde. Das ist nicht ganz richtig. CVE-2026-31431 ist ein Kernel-Fehler. Jeder Build, der anfällige Kernel-Versionen (eingeführt im Jahr 2017) verwendet, enthält den betroffenen Code, unabhängig davon, ob er von Canonical, Red Hat oder Ihrer eigenen Yocto-Pipeline erstellt wurde.

Diese Sicherheitslücke spielt jedoch nur dann eine Rolle, wenn CONFIG_CRYPTO_USER_API_AEAD ist aktiviert. Das ist das Modul, das AF_ALG für den Userspace zugänglich macht und den Exploit nutzbar macht.

Allgemeine Distributionen – Ubuntu, RHEL, Debian, SUSE – aktivieren diese Funktion standardmäßig. Das müssen sie auch. Sie decken ein breites Spektrum an Anwendungsfällen ab und können nicht vorhersagen, was der Endnutzer benötigt. Sie liefern alles mit, einschließlich der Angriffsfläche.

Yocto und Buildroot mit Standard- oder umfassenden Kernel-Konfigurationen befinden sich in derselben Situation. Ein Yocto-Build ist nicht automatisch sicherer als Ubuntu. Es hängt von den Entscheidungen ab, die bei der Konfiguration getroffen werden.

Ein ordnungsgemäß gehärteter Embedded-Kernel – bei dem jedes Modul auf die tatsächlichen Anforderungen des Geräts abgestimmt ist – ermöglicht wahrscheinlich nicht CONFIG_CRYPTO_USER_API_AEAD. Es gibt keinen Grund, warum ein chirurgisches Display oder eine industrielle Steuerung Zugriff auf Kernel-Krypto-Sockets im Userspace benötigen sollte. Das Gleiche gilt für Setuid-Binärdateien und nicht privilegierte Benutzerkonten – in einer Minimalinstallation sollten diese gar nicht vorhanden sein. (Anmerkung: Der veröffentlichte Proof-of-Concept nutzt Python, doch die zugrunde liegende Kernel-Primitive kann von jeder kompilierten Binärdatei aus ausgelöst werden. Das bloße Fehlen von Python reicht als Schutzmaßnahme nicht aus.)

Die Sicherheitslücke befindet sich im Kernel. Ob sie ausgenutzt werden kann, hängt von den Entscheidungen ab, die bei der Konfiguration des Betriebssystems getroffen wurden. OEMs, die bewusste, sicherheitsorientierte Entscheidungen bei der Kernel-Konfiguration getroffen haben, haben ihr Risiko je nach ihrer spezifischen Konfiguration möglicherweise verringert. Diejenigen, die eine Allzweck-Distribution – oder einen Yocto-Build mit Standardeinstellungen – ausgeliefert haben, sollten dies überprüfen.

Warum passiert das immer wieder?

„Copy Fail“ ist nicht die erste kritische Kernel-Sicherheitslücke (CVE) und wird auch nicht die letzte sein. Dirty Cow war 2016. Dirty Pipe war 2022. Das Muster wiederholt sich alle paar Jahre, und die Herausforderung bei der Reaktion ist immer dieselbe: Auswirkungen bewerten, ein gepatchtes Image erstellen, es validieren, auf die Geräte im Feld übertragen, alles für die Aufsichtsbehörde dokumentieren. Die Tools, die Copy Fail aufgedeckt haben – KI-gestützte Code-Analyse – werden weitere Schwachstellen finden. Die Entdeckungsrate wird sich bald beschleunigen.

Zwei Dinge sollten klar gesagt werden:

Der Patch ist nicht das Schwierige. Die Bereitstellung ist es. Ubuntu und RHEL haben diese Sicherheitslücke innerhalb weniger Tage behoben. Für eingebettete Geräte in Krankenhäusern, Fabriken und Fahrzeugen erfordert die Installation dieses Patches jedoch eine OTA-Infrastruktur, Transparenz über den Gerätebestand, eine regelkonforme Änderungskontrolle sowie eine erneute Validierung. Viele OEMs, die auf Allzweck-Distributionen setzen, verfügen nicht über diese Infrastruktur. Und der Betrieb apt-get update Die Installation auf einem regulierten Gerät führt zu einer unkontrollierten Reihe von Paketänderungen ohne Rückverfolgbarkeit, ohne Tests in Bezug auf Ihre Anwendung und ohne Rollback-Möglichkeit. In einer regulierten Umgebung ist das keine Abhilfe – es ist ein Compliance-Verstoß.

Achtung, Tools. Sie treffen keine Entscheidungen. CVE-Scanner und SBOM-Tools melden „Copy Fail“ innerhalb weniger Stunden. Sie prüfen jedoch nicht, ob CONFIG_CRYPTO_USER_API_AEAD ist in Ihrer Build-Version überhaupt aktiviert. Sie prüfen nicht, ob die Sicherheitslücke auf einem Gerät ohne nicht privilegierte Benutzer ausnutzbar ist. Sie liefern weder die gerätespezifische Folgenabschätzung noch die Entscheidung zur Behebung oder den Nachweis der Änderungskontrolle, die Ihre technische Dokumentation erfordert. Die Lücke zwischen einer Dashboard-Warnung und einer validierten, dokumentierten Behebung ist der Punkt, an dem die meisten OEMs Zeit verlieren.

Beide Probleme lassen sich auf dieselbe Ursache zurückführen: Das Betriebssystem wird als einmalige Integrationsentscheidung betrachtet und nicht als verwaltete Abhängigkeit mit einem mehrjährigen Lebenszyklus. Ein minimaler Kernel, der nur die Funktionen bereitstellt, die das Gerät benötigt, hätte keine algif_aead vor allem. Ein klar definierter Update-Pfad und eine langfristige Wartungsverpflichtung würden die Lücke bei der Bereitstellung schließen, sobald die nächste CVE bekannt wird.

Empfohlene Maßnahmen für OEMs

Wenn Sie Linux-basierte Embedded-Produkte entwickeln oder warten, haben wir hier einige Empfehlungen für Sie.

1. Überprüfen Sie zunächst Ihre Kernelkonfiguration. Bevor Sie davon ausgehen, dass Sie gefährdet sind, prüfen Sie, ob CONFIG_CRYPTO_USER_API_AEAD ist aktiviert:

zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API_AEAD

Wenn /proc/config.gz nicht auf Ihrem Zielsystem verfügbar ist (was bei minimalistischen Embedded-Builds häufig vorkommt), überprüfen Sie stattdessen Ihr Build-System: Sehen Sie sich die .config oder „defconfig“ in Ihrem Kernel-Quellcode-Verzeichnis ausführen grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r) bei Distributionen, die diese Datei dort speichern, oder in Yocto direkt in der `defconfig`-Datei Ihres Kernel-Rezepts.

Falls es zurückkommt not set oder nicht vorhanden ist, ist der bekannte Exploit-Pfad auf Ihrem Gerät nicht erreichbar. Dies ist ein entscheidender erster Schritt bei der Fehlerdiagnose.

2. Erstellen Sie eine Bestandsaufnahme Ihrer Kernel-Versionen. Ermitteln Sie, welche Kernel in Ihren Produktlinien und Ihrer gesamten Infrastruktur zum Einsatz kommen. Betroffen sind Kernel-Versionen ab 2017, die den anfälligen Code-Pfad enthalten und bei denen das Modul aktiviert ist.

3. Wenden Sie den Upstream-Patch an. Aktualisieren Sie auf Kernel-Builds, die den Fix enthalten. Gepatchte Versionen sind im stabilen Linux-Tree sowie über herstellerspezifische Backports verfügbar.

4. Ergreifen Sie Abhilfemaßnahmen, bevor Sie einen Patch installieren. Wenn Sie den Kernel nicht sofort aktualisieren können, deaktivieren Sie die algif_aead Modul, den Zugriff auf den AF_ALG-Socket mithilfe von seccomp einschränken und SELinux- oder AppArmor-Richtlinien anwenden, um zu begrenzen, welche Prozesse auf die kryptografische Socket-Schnittstelle zugreifen dürfen.

5. Überprüfen Sie die Annahmen zur Containerisolierung. Wenn Ihre Architektur Container zur Isolierung von Workloads auf einem gemeinsam genutzten Kernel einsetzt, ist diese Sicherheitslücke ein konkreter Beweis dafür, dass Container allein nicht als Sicherheitsgrenze herangezogen werden sollten. Prüfen Sie, ob Ihr Bedrohungsmodell eine Isolationsschicht auf Hardware- oder Hypervisor-Ebene erfordert.

6. Aktualisieren Sie Ihre SBOM und Ihre Schwachstellenaufzeichnungen. Dokumentieren Sie CVE-2026-31431 in Ihrer Software-Stückliste und Ihren Cybersicherheits-Risikobewertungen. Bei FDA-regulierten Produkten fließt dies in Ihren Cybersicherheits-Managementplan für die Zeit nach der Markteinführung ein. Im Rahmen der EU-MDR kann dies eine Vigilanzbewertung auslösen.

7. Planen Sie Ihr Update vor Ort. Legen Sie für bereits im Einsatz befindliche Geräte Ihren Update-Pfad fest. Wenn Sie über OTA verfügen, sollten Sie dieser Option den Vorrang geben. Falls nicht, ist dies der richtige Zeitpunkt, um darüber nachzudenken, wie Sie mit der nächsten kritischen Kernel-CVE umgehen werden – denn eine solche wird es geben.

8. Kommunizieren Sie mit Ihren Kunden. Informieren Sie Ihre Endkunden und klinischen Anwender über die Sicherheitslücke, Ihre Einschätzung und Ihren Zeitplan. Transparenz schafft Vertrauen.

Das umfassendere Signal

Noch eine letzte Anmerkung: „Copy Fail“ wurde im Rahmen einer KI-gestützten Codeüberprüfung entdeckt. Ein Forscher ließ ein automatisiertes Analyse-Tool das Krypto-Subsystem des Kernels untersuchen, und dieses identifizierte die Schwachstelle innerhalb von etwa einer Stunde. Ein Logikfehler, der neun Jahre lang unentdeckt geblieben war.

Für Hersteller eingebetteter Systeme ändern sich die Rahmenbedingungen. Die Zahl der entdeckten schwerwiegenden Kernel-Sicherheitslücken wird zunehmen. Die Frage ist nicht, ob Ihr Betriebssystem Sicherheitslücken aufweist – das tut es. Die Frage ist vielmehr, ob Ihre Entwicklungsprozesse, Ihre Update-Infrastruktur und Ihre behördlichen Unterlagen mit dieser Entwicklung Schritt halten können.

Haftungsausschluss: Dieser Artikel dient ausschließlich zu Informationszwecken und stellt keine rechtliche, behördliche oder sicherheitstechnische Beratung dar. Die Informationen geben allgemeine Beobachtungen zu einer öffentlich bekannt gewordenen Sicherheitslücke wieder und treffen möglicherweise nicht auf bestimmte Gerätekonfigurationen oder Einsatzumgebungen zu. Kunden und OEMs sind dafür verantwortlich, die Anwendbarkeit, die Auswirkungen und die Abhilfemaßnahmen in ihren eigenen Systemen zu bewerten, einschließlich der Einhaltung geltender behördlicher Anforderungen. L4B Software übernimmt keine Gewähr dafür, dass die bereitgestellten Informationen vollständig oder für einen bestimmten Verwendungszweck ausreichend sind.