Im Jahr 2024 entdeckte ein Forscherteam eine schwerwiegende Sicherheitslücke im CAN BCM Subsystem des Linux-Kernels, die als Use-after-free (UAF) klassifiziert wird. Diese Schwachstelle wurde unter der Kennung CVE-2023-52922 aufgezeichnet und betrifft vor allem Systeme, die Red Hat Enterprise Linux 9 mit Kernel-Version 5.14 verwenden. Obwohl der Fehler im Linux Kernel-Quellcode im Juli 2023 behoben wurde, blieb er in einigen Distributionen bis Mitte 2025 aktiv, bevor er vollständig gepatcht wurde. Die Use-after-free-Schwachstelle erlaubt es Angreifern ohne besondere Rechte, auf Kernel-Speicher zuzugreifen und damit potenziell vertrauliche Daten preiszugeben, was eine ernste Verletzung der Systemsicherheit darstellt.
Die Verwundbarkeit beruht darauf, dass im CAN BCM Subsystem temporäre Datenstrukturen nach ihrer Benutzung nicht korrekt gesichert freigegeben werden, wodurch ein Szenario entsteht, in dem eine bereits freigegebene Speicherstruktur erneut gelesen wird. Konkret spielen die proc-Einträge des CAN BCM Systems eine zentrale Rolle. Diese Einträge sind unter /proc/net/can-bcm/ zu finden und ermöglichen die Abfrage von Statusinformationen über den Socket. Beim parallelen Lesen und Schließen (close) eines Sockets kann es dazu kommen, dass die Liste von Operationen (tx_ops und rx_ops) freigegeben wird, während gleichzeitig versucht wird, aus denselben Daten zu lesen. Im Kern des Problems liegt die Funktion bcm_release(), die bei der Schließung eines CAN BCM Sockets einmal die Elemente aus tx_ops und rx_ops entfernt, indem die Funktion bcm_remove_op() aufgerufen wird, welche die betreffenden Strukturen freigibt.
Erst danach wird der entsprechende proc-Eintrag entfernt. In der kurzen Zeitspanne zwischen diesen zwei Aktionen kann ein anderer Prozess die Funktion bcm_proc_show() aufrufen, die eben jene freigegebenen Speicherstrukturen lesen und ausgeben möchte. Da der Speicher aber bereits freigegeben wurde, handelt es sich hierbei um eine klassischer Use-after-free-Zugriff. Die Auswirkungen solcher Use-after-free-Lücken sind vielfältig und gefährlich. Im vorliegenden Fall ermöglicht sie unprivilegierten Nutzern, sensible Kernel-Daten auszulesen.
Dies kann zum Beispiel dazu führen, dass verschlüsselte Kernel-Strukturen oder Zufallswerte, die zur Adressbereichs-Randomisierung (KASLR) genutzt werden, sichtbar werden. Der Abfluss solcher Informationen schwächt essenzielle Schutzmechanismen und kann als Basis für weiterführende Angriffe dienen, die schließlich zu einer vollständigen Kompromittierung des Systems führen. Die Analyse der technischen Details offenbart außerdem, wie der zugrundeliegende Speicher-Allocator (SLUB) verwendet wird. Das struct bcm_op weist eine Größe von 472 Bytes auf, wodurch es in den kmalloc-512 Cache klassifiziert wird. Ein wichtiges Detail ist, dass die freiwerdenen Objekte in der Liste als verkettete Listenobjekte organisiert sind, deren Zeiger an beliebiger Stelle in der Struktur stehen.
Wird nun dieselbe Speicheradresse mehrfach freigegeben und wiederverwendet, kann der Inhalt der Liste durch kontrollierte Objekte überschrieben werden, was eine Reihe von Exploits zulässt, etwa das Erzeugen endloser Schleifen oder das Auslesen von Speicherinhalten. Verschiedene Konzepte wurden ausprobiert, um die Schwachstelle auszunutzen. Ein Ansatz war die Manipulation der freien Listen-Pointer, indem der freie Speicher mit Objekten belegt wurde, die vom Angreifer kontrollierte Werte enthalten. So ist es möglich, über die proc-Einträge Zeiger auf beliebige Speicheradressen zu erhalten. Das führt im schlimmsten Fall zu einem General Protection Fault (GPF), wenn der Kernel versucht, eine unzulässige Adresse zu dereferenzieren.
Ein weiterer Experimentierpfad bestand darin, Objekt-Reallokationen vorzunehmen, die Endlosschleifen im Kernel auslösen können und somit das System unbrauchbar machen. Hierbei wurden System-V IPC-Nachrichten mit eigenen Listenkonfigurationen verwendet, um den freien Speicher zu besetzen und so die interne Schleifenlogik des CAN BCM Subsystems zu manipulieren. Am aussichtsreichsten ist allerdings die gezielte Informationsfreigabe. Durch Ausnutzen der Tatsache, dass die Use-after-free-Strukturen einen bestimmten Feldbereich für Zeitmessungen (kt_ival2) verwenden, der gleichzeitig genau in der Mitte der zwischengespeicherten Objekte liegt, konnten codierte Freelist-Zeiger ausgegeben werden. Diese Zeiger dienen intern der Speicherverwaltung für freie Objekte und sind mit zufälligen Werten (Randomisierung) verschleiert, um Angriffe zu erschweren.
Das Leaken dieser Zeiger ermöglicht es jedoch, sensible Kerneladressen aus dem Speicher auszulesen und somit die Sicherheitsmechanismen zur Speicheradressen-Randomisierung (KASLR) zu umgehen. Die gezielte Auswertung der geleakten Kodierungen zeigt, dass der Kernel zur Verschleierung mehrere XOR-Operationen mit einem Random-Wert sowie einer Byte-Swapping-Funktion für die Speicheradresse verwendet. Wird das letzte Codierungselement der freien Liste mit einer beliebigen Adresse verknüpft, lässt sich ein manipuliertes Element erzeugen, das beim Zugriff auf diese Adresse verweist. Diese Erkenntnis hat weitreichende Folgen. Zum einen ermöglicht es, gezielt kernelinterne Zeiger zu bestimmen und somit eine wichtige Schutzmaßnahme zu umgehen.
Zum anderen vereinfacht es potentiellen Folgeverletzungen die Arbiträre Speicheradresse etwa für gezielte Speicherveränderungen (Arbitrary Write) oder erweiterte Speicherlecks. Dabei besteht eine gewisse Einschränkung darin, dass die ausgelesenen Werte aufgrund der Umwandlung in Mikrosekunden mittels ktime_to_us() nicht exakt sind und leicht variieren, was jedoch durch eine clevere Anpassung der Exploit-Techniken umgangen werden kann. Der Gedanke, dass in komplexen und weitverbreiteten Subsystemen wie CAN BCM Muster sich wiederholen, wird durch weitere entdeckte Probleme bestätigt. Bereits seit 2015 wurden ähnliche Use-after-free- sowie Out-of-Bounds-Lese-Schwachstellen im CAN BCM System gefunden und gefixt, wie etwa frühere Fehler in bcm_connect und proc_register. Die Tatsache, dass auch nach Jahren relevante Schwachstellen vorhanden waren, verdeutlicht, wie schwierig es ist, Speicherfehler in diesen Kernkomponenten zu vermeiden.
Die Schwachstelle CVE-2023-52922 wurde nach der Entdeckung im Juli 2024 an Red Hat gemeldet. Obwohl der Kernel-Upstream bereits im Sommer 2023 einen Fix implementiert hatte, wurde die Korrektur erst im März 2025 in den entsprechenden Red-Hat-Distributionen zurückportiert, was eine Lücke von mehreren Monaten mit erhöhtem Risiko bedeutet. Die Ausnutzung setzt voraus, dass ein CAN-Netzwerkschnittstellen-Gerät verfügbar ist, was unter modernen Linux-Distributionen mit Unterstützung für virtuelle CAN-Tunnel (VXCAN) auch in Container- oder virtualisierten Umgebungen gegeben sein kann. In älteren Distributionen wie RHEL 8 ist VXCAN nicht standardmäßig eingebaut, womit das Risiko dort geringer ist. Die technische Untersuchung der Schwachstelle zeigt, wie wichtig eine genaue Überprüfung der Speicherverwaltungsmechanismen in Systemsubsystemen ist.
Fehlerhafte Synchronisation von Freigabeoperationen und dem parallelen Zugriff auf proc-Prozeduren eröffnet einen kritischen Vektor für Informationslecks. Abschließend bleibt zu betonen, dass diese Schwachstelle exemplarisch verdeutlicht, dass auch vermeintlich vertraute und standardmäßig in Betrieb befindliche Subsysteme unerwartete Sicherheitslücken aufweisen können. Der Linux-Kernel ist ein komplexes Ökosystem mit ständigen Entwicklungen, bei dem proprietäre und offene Entwickler zusammenarbeiten. Eine kontinuierliche Pflege, Quartals-Backports von Sicherheits-Patches sowie aktive Sicherheitsforschung sind essenziell, um die Stabilität und Sicherheit solcher Systeme zu gewährleisten. Systemadministratoren und Betreiber von Linux-Servern sollten dringend sicherstellen, dass die neuesten Kernel-Updates eingespielt sind, insbesondere wenn CAN BCM Subsysteme verwendet werden.
Für Anwender in sicherheitskritischen Umgebungen ist es empfehlenswert, eine mögliche Angriffsfläche so gering wie möglich zu halten und Zugriffe auf CAN-Netzwerkschnittstellen zu kontrollieren beziehungsweise einzuschränken. Informationen zur Schwachstelle, technische Details und Proof-of-Concept-Code wurden von Forschern einer renommierten Security-Firma veröffentlicht und umfassend dokumentiert. Die Erkenntnisse helfen Entwicklern dabei, bestehende und zukünftige Sicherheitslücken besser zu verstehen und zu vermeiden. Die Veröffentlichung unterstreicht die Bedeutung eines kooperativen Ansatzes zwischen Forschern, Kernel-Maintainern und Distributionen, um Sicherheitslücken schnell zu identifizieren und zu beheben und somit den Linux-Kernel als eines der wichtigsten Betriebssystem-Backbones für Industrie, Forschung und Endverbraucher zu schützen.
