CVE-2025-38100 in Linux
Zusammenfassung
von VulDB • 23.06.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
x86/iopl: Behebung von Inkonsistenzen bei TIF_IO_BITMAP
io_bitmap_exit() wird aus exit_thread() aufgerufen, wenn ein Task beendet wird oder wenn ein Fork-Vorgang fehlschlägt. Im letzteren Fall räumt exit_thread() Ressourcen auf, die während des Forks alloziert wurden.
io_bitmap_exit() ruft task_update_io_bitmap() auf, was wiederum zu tss_update_io_bitmap() führt. tss_update_io_bitmap() arbeitet mit dem aktuellen Task (current). Wenn current das Flag TIF_IO_BITMAP gesetzt hat, aber kein Bitmap installiert ist, stürzt tss_update_io_bitmap() aufgrund einer NULL-Zeiger-Dereferenzierung ab.
Es gibt zwei Probleme, die zu dieser Situation führen:
1) io_bitmap_exit() sollte task_update_io_bitmap() nicht aufrufen, wenn der aufgeräumte Task nicht der aktuelle Task (current) ist. Dies deutet eindeutig auf eine Aufräumarbeit nach einem fehlgeschlagenen Fork hin.
2) Ein Task darf weder das Flag TIF_IO_BITMAP gesetzt haben noch ein Bitmap installiert sein oder die IOPL-Emulationsstufe 3 aktiviert haben.
Dies tritt auf, wenn ein Kernel-Thread im Kontext eines User-Space-Threads erstellt wird, bei dem TIF_IO_BITMAP als Thread-Flag kopiert wurde und der Zeiger auf das IO-Bitmap gelöscht ist.
Anders als beim fehlgeschlagenen Fork hat dies keine Auswirkungen, da Kernel-Threads (einschließlich IO-Arbeiter) niemals in den User-Space zurückkehren und daher tss_update_io_bitmap() nie aufrufen.
Dies wird behoben, indem die fehlenden Aufräumarbeiten und Prüfungen hinzugefügt werden:
1) Verhindern Sie, dass io_bitmap_exit() task_update_io_bitmap() aufruft, wenn der aufzuräumende Task nicht der aktuelle Task ist.
2) Löschen Sie TIF_IO_BITMAP in copy_thread() bedingungslos. Bei User-Space-Forks wird es später gesetzt, wenn das IO-Bitmap in io_bitmap_share() geerbt wird.
Aus Sicherheitsbedenken wurde eine Warnung in tss_update_io_bitmap() eingefügt, um den Fall abzufangen, in dem dieser Code mit einem inkonsistenten Zustand aufgerufen wird.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.