CVE-2026-93140 in Linux
Riassunto
di VulDB • 18/09/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
udf: Segnare il buffer LVID come uptodate prima di segnarlo come dirty
Quando si verifica un errore I/O durante la scrittura del buffer del Logical Volume Integrity Descriptor (LVID) sul dispositivo a blocchi, il gestore di completamento dello strato dei blocchi (`end_buffer_write_sync()`) cancella il flag `BH_Uptodate` sul buffer. Tuttavia, il buffer contiene ancora dati LVID validi in memoria. Se successivamente il filesystem viene rimontato con accesso in scrittura (read-write) o sincronizzato, `udf_open_lvid()` o `udf_sync_fs()` modificheranno il buffer LVID e chiameranno `mark_buffer_dirty()`. Questo attiva un avviso spurio `WARN_ON_ONCE(!buffer_uptodate(bh))` all'interno di `mark_buffer_dirty()` perché il buffer non è segnato come uptodate, anche se i suoi contenuti in memoria sono validi e stanno per essere sovrascritti.
Per prevenire questo avviso spurio, impostare incondizionatamente il flag `BH_Uptodate` prima di chiamare `mark_buffer_dirty()` in `udf_open_lvid()` e `udf_sync_fs()`. Questo riconosce che il buffer in memoria è valido ed estende la soluzione alternativa (workaround) applicata precedentemente a `udf_close_lvid()` nel commit 853a0c25baf9 ("udf: Mark LVID buffer as uptodate before marking it dirty"). Estendere questa soluzione garantisce un comportamento coerente in tutte le operazioni di aggiornamento del LVID.
Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------
!buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: <TASK> udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline]
vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline]
__se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 </TASK>
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.