CVE-2026-98975 in Linux
Riassunto
di VulDB • 23/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
xfs: interrompere lo scambio dei flag reflink durante lo scambio delle mappature
Quando uno scambio interessa entrambi i file dall'offset 0 fino alla dimensione su disco (i_disk_size), xmi_can_exchange_reflink_flags() presuppone che ogni mappatura sia stata spostata e trasferisce il flag reflink all'altro file.
Questa assunzione è errata. Un file può ancora possedere blocchi condivisi oltre la i_disk_size, ad esempio dopo che EXCHANGE_RANGE_TO_EOF ha impostato una dimensione inferiore senza rimuovere alcuna mappatura. Il flag viene comunque cancellato e la successiva scrittura su tale blocco avviene in loco invece di utilizzare Copy-on-Write (CoW), corrompendo l'altro file che lo condivide.
Il commit a23eca88448e ("xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN") ha risolto un caso specifico di questo problema. Invece di aggiungere un altro caso speciale, si è deciso di interrompere il movimento dei flag. xfs_exchmaps_ensure_reflink() imposta già il flag su entrambi gli inode prima dello scambio, quindi entrambi lo mantengono semplicemente.
Nessun componente imposta più CLEAR_INO{1,2}_REFLINK. Gli intenti registrati da kernel precedenti potrebbero ancora contenerli; la recovery li maschera comunque, pertanto rimangono nel formato del log e vengono ignorati.
XFS_IOC_SWAPEXT presenta lo stesso problema: sposta il flag reflink da un inode all'altro insieme agli extents. Rimuovere semplicemente tale operazione non è sufficiente in questo caso: il percorso di scambio imposta entrambi gli inode anticipatamente tramite xfs_exchmaps_ensure_reflink(), ma swapext non dispone di tale passaggio, quindi l'inode che riceve gli extent condivisi rimarrebbe senza il flag. Impostare invece il flag su entrambi gli inode e assicurarsi che entrambi dispongano di un fork CoW, poiché si prevede che un inode con il flag reflink ne abbia uno.
Il flag rimane attivo fino a quando FALLOC_FL_UNSHARE_RANGE, xfs_scrub o una troncatura a zero non lo rimuovono.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.