CVE-2026-98924 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
fs: Vermeidung wiederholter Scans in evict_inodes()
Wir haben beobachtet, dass Tasks hängen blieben (hung tasks), wenn Benutzer versuchten, ein Dateisystem zu unmounten, nachdem dessen Datenträger entfernt worden war, während er noch in Verwendung war. Während der Geräteentfernung ruft fs_bdev_mark_dead() evict_inodes() auf, wobei s_umount gehalten wird.
Jedes Mal, wenn evict_inodes() das Sperren von s_inode_list_lock aufgibt, um neu zu planen (reschedule), beginnt es den Durchlauf wieder am Anfang der Liste von s_inodes. Bei vielen referenzierten Inodes am Anfang der Liste führen diese Neustarts dazu, dass dieselben Inodes wiederholt gescannt werden, ohne sie zurückzugewinnen (reclaiming). Dies kann dazu führen, dass s_umount für eine lange Zeit gehalten wird, was gleichzeitige Unmount-Versuche blockiert und Berichte über hängende Tasks auslöst.
Halten Sie den aktuellen Inode, der bereits mit I_FREEING markiert ist, von dem Batching zur Entsorgung (disposal batch) fern, bis s_inode_list_lock wieder erworben wird. Setzen Sie den Durchlauf ab diesem Inode fort und entsorgen Sie ihn in einem späteren Batch oder am Ende des Durchlaufs.
Die Prüfungen der Referenzanzahl null und des Zustands unter i_lock ermöglichen es diesem Walker (Durchlaufer), den Inode zu beanspruchen, indem er I_FREEING setzt und ihn aus dem LRU entfernt. Andere Reclaimer überspringen diesen Inode, sodass dieser Walker für die Eviktion verantwortlich bleibt. Nur evict() entfernt ihn von s_inodes; daher stellt das Ausschließen aus dem Batching zur Entsorgung sicher, dass er auf der Liste verbleibt, während die Sperre freigegeben wird. Nach dem erneuten Erwerben der Sperre berücksichtigt das Lesen seines aktuellen Next-Pointers den gleichzeitigen Entfernen folgender Inodes.
Die bestehenden Regeln für die Lebensdauer von Inodes verbieten es, eine Referenz zu einem mit I_FREEING oder I_WILL_FREE markierten Inode zu erwerben. __iget() erfordert, dass sein Aufrufer i_lock hält und sicherstellt, dass das Erwerben einer Referenz gültig ist. Die Inode-Suche (inode lookup) und igrab() prüfen diese Flags unter i_lock beim Erwerb einer Referenz von null. ihold() erfordert eine bestehende Referenz, die dazu führen würde, dass i_count nicht null wird und dieser Walker den Inode nicht beanspruchen kann. Diese Regeln erlauben es bereits iput_final() und dem Inode-Shrinker (Inode-Schrumpfer), i_lock nach dem Setzen von I_FREEING und vor Abschluss der Eviktion freizugeben.
Eine temporäre __iget()-Referenz würde den Inode ebenfalls auf der Liste halten, aber ihre Freigabe muss die Behandlung des letzten Referenzzählers bewahren. Ein anderer Benutzer kann eine Referenz erwerben, lazy timestamps aktualisieren und seine Referenz freigeben, während das Pinning gehalten wird. Wenn das Pinning zur letzten Referenz wird, würde das Herunterzählen mit atomic_dec_and_test() und ein direktes Eviktieren die lazytime-Behandlung von iput() umgehen und diese Zeitstempelaktualisierungen könnten verloren gehen.
Das Freigeben des Pinnings mit iput() bewahrt diese Behandlung, garantiert jedoch keine Eviktion. fs_bdev_mark_dead() wird ausgeführt, während SB_ACTIVE gesetzt ist; daher kann iput() den Inode im Cache behalten, wohingegen evict_inodes() eligible Inodes mit null Referenzanzahl eviktieren muss. Der Inode könnte auch bereits freigegeben worden sein, wenn iput() zurückkehrt, sodass der Walker ihn dann nicht mehr verwenden kann, um eine Eviktion zu erzwingen. Die Verwendung von I_FREEING bewahrt das bestehende Eviktionsverhalten, ohne einen zusätzlichen Übergang des letzten Referenzzählers einzuführen.
Die xfstests-Automatikgruppe bestand auf ext4 und XFS mit bekannten, nicht zusammenhängenden Fehlern, die ausgeschlossen wurden. Es wurden keine neuen Probleme beobachtet, und der zuvor reproduzierbare hängende Task tritt mit diesem Patch nicht mehr auf.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.