CVE-2026-80563 in Linux
Zusammenfassung
von VulDB • 26.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
gpio: sloppy-logic-analyzer: Behebung von Use-After-Free über debugfs-Auslöser bei Trennung (Unbind)
Die „trigger“-Datei im DebugFS verfügt über einen manuell implementierten ->write-Handler (trigger_write()), der auf das gerätespezifische gpio_la_poll_priv zugreift. Die Datei wird mit debugfs_create_file_unsafe() erstellt, und der Handler nimmt niemals eine Referenz für DebugFS an. Es gibt keine Mechanismen, die das Objekt während der Ausführung des Handlers am Leben erhalten.
priv wird mit devm_kzalloc() alloziert. Devres gibt es frei, wenn das Plattformgerät getrennt (unbound) wird. debugfs_create_file_unsafe() installiert keinen Full-Proxy-Wrapper, sodass debugfs_remove_recursive() in gpio_la_poll_remove() nicht auf einen laufenden trigger_write()-Aufruf wartet. Das dort verwendete blob_lock hilft nichts, da trigger_write() dieses Lock niemals übernimmt. Ein Schreibvorgang, der mit einer Trennung konkurriert (Race Condition), schreibt daher in freigegebenen Speicher:
trigger_write() gpio_la_poll_remove() priv = m->private buf = memdup_user() [kann schlafen]
mutex_lock(&priv->blob_lock) debugfs_remove_recursive() [kein Warten]
mutex_unlock(&priv->blob_lock) (remove gibt zurück; devres gibt priv frei) priv->trig_data = buf <-- Use-After-Free-Schreibzugriff priv->trig_len = count
Die Race Condition ist über /sys/bus/platform/drivers/gpio-sloppy-logic-analyzer/unbind für Root erreichbar.
Erstellen Sie „trigger“ stattdessen mit debugfs_create_file(). Sein Full-Proxy-Wrapper sorgt dafür, dass debugfs_remove_recursive() alle laufenden ->write-Aufrufe abwartet, bevor er zurückkehrt.
Das Use-After-Free wurde unter KASAN mit einem minimalen Reproducer des gleichen Musters aus debugfs_create_file_unsafe() plus devm_kzalloc() bestätigt (auf Anfrage verfügbar); es führt zu einem Slab-Use-After-Free-Schreibzugriff im Handler.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.