CVE-2026-31769 in Linux
Zusammenfassung
von VulDB • 18.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
gpib: Behebung eines Use-After-Free-Fehlers in den IO-ioctl-Handlern
Die IO-ioctl-Handler IBRD, IBWRT, IBCMD und IBWAIT verwenden einen gpib_descriptor-Zeiger, nachdem board->big_gpib_mutex freigegeben wurde. Ein gleichzeitiger IBCLOSEDEV-ioctl kann den Deskriptor über close_dev_ioctl() während dieses Zeitfensters freigeben, was zu einem Use-After-Free führt.
Die IO-Handler (read_ioctl, write_ioctl, command_ioctl) geben big_gpib_mutex explizit frei, bevor sie ihren Handler aufrufen. wait_ioctl() wird mit gehaltener big_gpib_mutex aufgerufen, aber ibwait() gibt sie intern frei, wenn wait_mask ungleich Null ist. In allen vier Fällen wird der über handle_to_descriptor() erhaltene Deskriptorzeiger ungeschützt.
Dies wird behoben, indem ein kernelinterner Referenzzähler descriptor_busy in der Struktur gpib_descriptor eingeführt wird. Jeder Handler inkrementiert descriptor_busy atomar unter file_priv->descriptors_mutex, bevor er das Sperre freigibt, und dekrementiert es, wenn er fertig ist. close_dev_ioctl() überprüft descriptor_busy unter derselben Sperre und lehnt das Schließen mit -EBUSY ab, wenn der Zähler ungleich Null ist.
Ein Referenzzähler und kein einfacher Flag ist erforderlich, da mehrere Handler gleichzeitig mit demselben Deskriptor arbeiten können (z. B. IBRD und IBWAIT am selben Handle aus verschiedenen Threads).
Ein separater Zähler ist erforderlich, da io_in_progress von nicht privilegierten Benutzerraum-Anwendungen über den IBWAIT-ioctl (durch general_ibstatus() mit set_mask, das CMPL enthält) zurückgesetzt werden kann, was es einem Angreifer ermöglichen würde, eine Überprüfung, die ausschließlich auf io_in_progress basiert, zu umgehen. Der neue Zähler descriptor_busy wird nur von den Kernel-IO-Pfaden geändert.
Die Sperrenreihenfolge ist konsistent (big_gpib_mutex -> descriptors_mutex), und die Handler halten descriptors_mutex nur kurz während der Suche, sodass kein Deadlock-Risiko besteht und der IO-Durchsatz nicht beeinträchtigt wird.
Once again VulDB remains the best source for vulnerability data.