Die Linux-Sicherheit steht nach der Entdeckung der Schwachstelle CVE-2026-31431, von Forschern von Xint Code als „Copy Fail“ bezeichnet, vor einer weiteren Herausforderung. Diese Sicherheitslücke ist alles andere als ein theoretischer Fehler; sie ermöglicht es einem lokalen Benutzer ohne Administratorrechte, seine Berechtigungen auszuweiten und auf vorhersehbare und unbemerkte Weise vollen Superuser-Zugriff zu erlangen.
Die Forscher weisen darauf hin, dass diese Schwachstelle in führenden Distributionen wie Ubuntu, Amazon Linux, RHEL und SUSE erfolgreich ausgenutzt wurde. Dies bestätigt, dass jedes System, das mit einem Kernel ab Version 4.14 läuft und die Unterstützung für AF_ALG-Sockets aufrechterhält , potenziell anfällig für diesen Angriff ist.
In-Place-Operationen und Seitencache-Überlauf
Bezüglich der Sicherheitslücke wird erwähnt, dass sie auf eine 2017 eingeführte Optimierung der kryptografischen API des Kernels (AF_ALG) zurückgeht. Diese Modifikation zielte darauf ab, unnötiges Puffern zu vermeiden, indem authentifizierte Verschlüsselungsoperationen (AEAD) direkt im selben Speicherbereich ausgeführt werden, sogenannte „In-Place“-Operationen.
Das kritische Problem entsteht bei der Kombination dieser Optimierung mit der Funktion `splice()`, die Daten zwischen Dateideskriptoren überträgt, indem sie direkte Verweise auf den Kernel-Seitencache überträgt, anstatt die Daten physisch zu kopieren. Bei der Anforderung einer Entschlüsselung war die Speicherstruktur so konfiguriert, dass der Zielpuffer, der eigentlich ein temporärer Speicherbereich für den Benutzer sein sollte, direkt mit den Cache-Seiten verknüpft wurde, die die Systemdateidaten enthielten.
Authentifizierung und Schreiben außerhalb der Speichergrenzen
Die eigentliche Ursache für die Sicherheitslücke liegt im anomalen Verhalten des Authentifizierungsalgorithmus. Anders als andere kryptografische Verfahren, die die Grenzen ihrer Zielpuffer strikt einhalten, nutzt dieser Algorithmus den Benutzerspeicher als temporären Arbeitsbereich (Notizblock), um Bytefolgen während der Berechnung der Authentifizierungs-Tags neu anzuordnen.
Dabei schreibt der Algorithmus vier Bytes über die festgelegte Grenze des Ausgabebereichs hinaus. Aufgrund der In-Place-Optimierung und der von `splice()` erzeugten Referenzkette überschreitet dieser scheinbar harmlose Schreibvorgang die Grenze des Benutzerspeichers und landet direkt in der Kernel-Cache-Seite, die der verarbeiteten Datei zugeordnet ist.
Diese Kette logischer Fehler ermöglicht es dem Angreifer, beliebig vier Bytes an bestimmten Positionen im Seitencache jeder lesbaren Datei zu überschreiben. Durch das Senden einer Reihe berechneter Anfragen kann ein Angreifer Schadcode in die im Arbeitsspeicher befindliche Version kritischer ausführbarer Dateien mit gesetztem SUID-Bit einschleusen, beispielsweise in das Benutzerwechsel-Tool.
Da alle Leseoperationen zunächst den Seitencache abfragen, führt das System beim nächsten Aufruf des legitimen Programms den eingeschleusten Code aus dem Speicher aus und erlangt so sofort Root-Rechte, ohne die physische Datei auf der Festplatte zu verändern. Noch alarmierender ist, dass diese Schwachstelle, da die Containerisolation den Seitencache des zugrunde liegenden Hosts mitnutzt, als direktes Einfallstor dient, um aus virtualisierten Umgebungen wie Kubernetes-Clustern auszubrechen und den primären Knoten zu kompromittieren.
Notfallreparaturen und Abhilfemaßnahmen
Angesichts der Schwere dieses Fehlers haben die Wartungsteams Notfall-Updates bereitgestellt, bei denen die endgültige Lösung darin besteht, die In-Place-Optimierung in der Datei algif_aead.c rückgängig zu machen und die Quell- und Zielspeicherlisten strikt zu trennen, um zu verhindern, dass Cache-Seiten in beschreibbaren Pfaden landen.
Diese Patches wurden bereits in die Kernel 6.18.22, 6.19.12 und 7.0 integriert und werden in die Langzeitunterstützungszweige zurückportiert. Administratoren, die ihre Server nicht sofort neu starten oder aktualisieren können, wird empfohlen, das Kernelmodul algif_aead zu deaktivieren, falls es extern kompiliert wurde, oder die Erstellung von AF_ALG-Sockets mithilfe von Sicherheitsrichtlinien wie SELinux stark einzuschränken. SELinux schützt beispielsweise aktuelle Android-Geräte vor dieser Bedrohung.
Sollten Sie mehr erfahren wollen, finden Sie die Details unter folgendem Link.