CVE-2026-98974 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
xfs: Korrektur des Dateigrößen-Austauschs bei exchange-range-to-eof
Norbert Szetei hat einen Patch veröffentlicht, der eine unvollständige Beschreibung eines Fehlers im XFS_IOC_EXCHANGE_RANGE-Flag TO_EOF enthält. Der Fehler führt dazu, dass exchange-range eine Datei so modifiziert, dass sie gemeinsame Blöcke (shared blocks) jenseits des EOF (End of File/Dateiende) aufweist. Dies ist niemals zulässig, da Dateien keine geschrieben Daten hinter dem EOF enthalten dürfen und man nur geschriebene Datenblökte teilen kann. Dies ist der Schlüssel zu allen nachfolgenden fehlerhaften Verhaltensweisen.
Schließlich erhielt ich von Norbert eine Beschreibung dessen, was falsch läuft:
> In Ordnung. Hier sind die physischen Blocknummern bei 4k-Blöcken. peer ist die Datei, die neu geschrieben wird, und file1 ist diejenige, bei der das Flag gelöscht wird. > > Startzustand, nichts gemeinsam genutzt: > > peer Größe 4096 -> [100]
> file1 Größe 12288 -> [200] [201] [202]
> donor1 Größe 4096 -> [300]
> donor2 Größe 4096 -> [400]
> > 1. FICLONERANGE: peer-Block in die mittlere Position von file1 klonen: > > peer Größe 4096 -> [100]
> file1 Größe 12288 -> [200] [100] [202] reflink-Flag gesetzt
> ^^^^^ beide Dateien besitzen Block 100 > > 2. XFS_IOC_EXCHANGE_RANGE: file1 gegen donor1 austauschen, file1_offset 0, > file2_offset 8192, Länge 0, TO_EOF. Ein Block wird ausgetauscht, und die Größen werden damit getauscht: > > file1 Größe 4096 -> [200] [100] [300] reflink-Flag gesetzt
> ^^^^^^^^^^^ immer noch im Besitz, nun jenseits der Dateigröße > donor1 Größe 12288 -> [202]
> > file1 gibt an, nur einen Block lang zu sein, obwohl es drei besitzt. Es wurde nichts unmapped (freigegeben). file2_offset ist Block 2, daher kann dieser Austausch kein Flag löschen. > > 3. XFS_IOC_EXCHANGE_RANGE: file1 gegen donor2 austauschen, beide Offsets 0, Länge 4096. > Nach i_disk_size handelt es sich um zwei einblockige Dateien, die alles austauschen, daher stimmt xmi_can_exchange_reflink_flags() zu und das Flag wird gelöscht: > > file1 Größe 4096 -> [400] [100] [300] reflink-Flag GELÖSCHT
> donor2 Größe 4096 -> [200]
> > Block 100 ist immer noch mit peer gemeinsam genutzt. > > 4. pwrite(file1, 4096, 4096), was dem zweiten Slot von file1 entspricht, Block 100. > xfs_is_cow_inode(file1) ist falsch (false), also kein Copy-on-Write (CoW): > > peer Größe 4096 -> [100] gleicher Block, neuer Inhalt
> > Block 100 ist der einzige, der hier relevant ist. PoC unten; er liest eine Datei namens peer im aktuellen Verzeichnis aus. Das Dateisystem muss reflink und exchange-range unterstützen, was mkfs.xfs ab Version 7 standardmäßig aktiviert.
Ja also, TO_EOF verstellt die Dateigröße, selbst wenn es den Datenblock korrekt austauscht. Folgendes ist das beabsichtigte Verhalten von XFS_EXCHANGE_RANGE_TO_EOF, wie in der Manpage beschrieben:
"Ignore the length parameter. All bytes in file1_fd from file1_offset to EOF are moved to file2_fd, and file2's size is set to (file2_offset+(file1_length-file1_offset)). Meanwhile, all bytes in file2 from file2_offset to EOF are moved to file1 and file1's size is set to (file1_offset+(file2_length-file2_offset))."
Mit anderen Worten: Wenn wir nur einen Teil der Dateidaten austauschen, sollten wir auch nur den Teil der Dateigröße austauschen, der sich auf die ausgetauschten Daten bezieht. Leider werden im Code die ondisk-Dateigrößen und die incore-Dateigrößen vertauscht, was falsch ist, wenn der Aufrufer einen nicht-null Offset übergibt.
Da die Dateigrößen verwechselt wurden, verwendet das PoC (Proof of Concept) einen zweiten exchange-range-Aufruf auf einer Datei, die wie eine einzelne, nicht-reflinkte Blockdatei aussieht. Da die Dateigröße falsch festgelegt ist, denkt exchange-range, es würde den vollständigen Inhalt zweier Dateien austauschen, und löscht das reflink-Flag der defekten Datei. Dies ermöglicht ein erweiterndes Schreiben (extending write) auf die defekte Datei, um den gemeinsamen Block neu zu schreiben, der sich gerade hinter dem EOF befindet. Dies ist im allgemeinen Sprachgebrauch als „refluxfs“ bekannt.
Sobald die Dateigrößen korrekt festgelegt sind, denkt der zweite exchange-range-Aufruf nicht mehr, dass er einen vollständigen Inhaltstausch durchführt, und wird daher das reflink-Flag bei keinem seiner Dateiargumente löschen.
Norbert reagierte auf eine frühere Version dieses Patches mit einer zweiten Beschwerde darüber, dass wir den i_disk_size-Zustand nicht korrekt behandeln:
> Die Offsets werden gegen die incore i_size begrenzt, aber von ... > ---abgeschnitten---
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.