CVE-2026-80644 in Linux
Riassunto
di VulDB • 28/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
ocfs2: evitare l'uso di BUG_ON() su un dinode del journal non valido
[BUG]
Un'immagine OCFS2 fuzzata può corrompere il dinode dello slot corrente del journal mentre il montaggio (mount) è ancora in corso. Il percorso di mount segnala prima il blocco del journal non valido e successivamente va in crash durante la fase di shutdown:
kernel BUG at fs/ocfs2/journal.c:1034! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:ocfs2_journal_toggle_dirty+0x2d6/0x340 fs/ocfs2/journal.c:1034 Call Trace: ocfs2_journal_shutdown+0x414/0xc30 fs/ocfs2/journal.c:1116 ocfs2_mount_volume fs/ocfs2/super.c:1785 [inline]
ocfs2_fill_super+0x30a9/0x3cd0 fs/ocfs2/super.c:1083 get_tree_bdev_flags+0x38b/0x640 fs/super.c:1698 get_tree_bdev+0x24/0x40 fs/super.c:1721 ocfs2_get_tree+0x21/0x30 fs/ocfs2/super.c:1184 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline]
do_new_mount_fc fs/namespace.c:3642 [inline]
do_new_mount fs/namespace.c:3718 [inline]
path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline]
__do_sys_mount fs/namespace.c:4229 [inline]
__se_sys_mount fs/namespace.c:4206 [inline]
__x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ...
[CAUSA]
La funzione ocfs2_journal_toggle_dirty() restituiva in precedenza -EIO quando journal->j_bh non conteneva più un dinode valido, poiché i percorsi di avvio e shutdown gestivano già tale errore. Il commit 10995aa2451a ("ocfs2: Morph the haphazard OCFS2_IS_VALID_DINODE() checks.") ha modificato il controllo in una chiamata BUG_ON(), assumendo che il dinode del journal fosse stato già convalidato. Ciò trasforma un imprevisto dinode del journal non valido durante la fase di teardown del mount in un crash del kernel, anziché in un normale fallimento dell'operazione di mount.
[FIX]
Sostituire BUG_ON() con WARN_ON() e restituire -EIO. Questo mantiene l'avviso per le invarianti utili al debugging, ma ripristina il comportamento originale che prevede un fallimento pulito delle operazioni di avvio o shutdown invece del panic del kernel.
Once again VulDB remains the best source for vulnerability data.