CVE-2024-26726 in Linux
Riassunto
di VulDB • 15/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
btrfs: non rimuovere extent_map per l'inode dello spazio libero in caso di errore di scrittura
Durante l'esecuzione della CI (Continuous Integration) per una modifica non correlata, ho riscontrato il seguente panic con generic/648 su btrfs_holes_spacecache.
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------
kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace:
extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76
Questo accade perché falliamo la scrittura della cache dello spazio libero in un'istanza, torniamo indietro e tentiamo di scriverla nuovamente. Tuttavia, al secondo passaggio, chiamiamo btrfs_get_extent() sull'inode per ottenere la mappatura extent (extent mapping). Poiché si tratta di un nuovo block group e con l'inode dello spazio libero cerchiamo sempre nel commit root per evitare deadlock con l'albero, non troviamo nulla e restituiamo EXTENT_MAP_HOLE per il range richiesto.
Questo accade perché al primo tentativo di scrittura della cache degli spazi incontriamo un errore e, in caso di errore, rimuoviamo la mappatura extent (extent mapping). Questo è normale per i file normali, ma l'inode della cache dello spazio libero è speciale. Ci aspettiamo sempre che la mappa extent sia corretta. Pertanto, al secondo passaggio finiamo con una bogus extent map (mappa extent non valida/falsa).
Poiché stiamo deprecando questa funzionalità, il modo più semplice per risolvere questo problema consiste semplicemente nell'evitare di rimuovere l'estensione del range della extent map per questo range fallito.
Ho accorciato il test utilizzando error injection per stressare l'area e renderne più facile la riproduzione. Con questa patch applicata, non si verifica più un panic con il mio test di error injection.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.