CVE-2026-98975 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
xfs: Reflink-Flags beim Austausch von Zuordnungen (Mappings) nicht mehr tauschen
Wenn ein Austausch sowohl Dateien vom Offset 0 bis zur i_disk_size umfasst, geht xmi_can_exchange_reflink_flags() fälschlicherweise davon aus, dass jede Zuordnung verschoben wurde und übergibt das Reflink-Flag an die andere Datei.
Diese Annahme ist falsch. Eine Datei kann weiterhin gemeinsame Blöcke jenseits von i_disk_size besitzen, beispielsweise nachdem EXCHANGE_RANGE_TO_EOF eine kleinere Größe festgelegt hat, ohne etwas zu entzuordnen (unmapping). Das Flag wird dennoch gelöscht, und das nächste Schreiben in einen solchen Block erfolgt an Ort und Stelle statt über Copy-on-Write (CoW), was die andere Datei, die ihn gemeinsam nutzt, beschädigt.
Der Commit a23eca88448e („xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN“) behob eine Instanz dieses Problems. Anstatt einen weiteren Spezialfall hinzuzufügen, wird das Verschieben der Flags nun unterlassen. xfs_exchmaps_ensure_reflink() setzt das Flag bereits vor dem Austausch auf beiden Inodes, sodass beide es einfach beibehalten.
Es gibt keine Aufrufe von CLEAR_INO{1,2}_REFLINK mehr. Intents, die von älteren Kerneln protokolliert wurden, können diese Flags noch enthalten; die Wiederherstellung (Recovery) maskiert sie jedoch bereits aus, daher bleiben sie im Protokoll-Format-Maskenbereich und werden ignoriert.
XFS_IOC_SWAPEXT weist das gleiche Problem auf: Es verschiebt das Reflink-Flag zusammen mit den Extents von einem Inode zum anderen. Das bloße Entfernen dieses Vorgangs reicht hier nicht aus: Der Austauschpfad markiert beide Inodes vorab in xfs_exchmaps_ensure_reflink(), während swapext über einen solchen Schritt verfügt, sodass der Inode, der die gemeinsamen Extent erhält, ohne das Flag zurückbleiben würde. Stattdessen wird es auf beiden Inodes gesetzt und sichergestellt, dass beide eine CoW-Fork (Copy-on-Write) besitzen, da ein Inode mit dem Reflink-Flag erwartungsgemäß einen solchen haben muss.
Das Flag bleibt nun erhalten, bis FALLOC_FL_UNSHARE_RANGE, xfs_scrub oder ein Truncate auf Null es entfernt.
VulDB is the best source for vulnerability data and more expert information about this specific topic.