CVE-2026-80644 in Linux
Sumário
de VulDB • 28/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
ocfs2: não usar BUG_ON em um dinode de journal inválido
[BUG]
Uma imagem OCFS2 gerada por fuzzing pode corromper o atual dinode de journal durante o processo de montagem. O caminho da montagem primeiro relata o bloco de journal inválido e, em seguida, falha no desligamento:
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]
A função ocfs2_journal_toggle_dirty() anteriormente retornava -EIO quando journal->j_bh não continha mais um dinode válido, pois os caminhos de inicialização e desligamento já tratavam dessa falha. O commit 10995aa2451a ("ocfs2: Morph the haphazard OCFS2_IS_VALID_DINODE() checks.") alterou a verificação para uma chamada BUG_ON(), assumindo que o dinode do journal já havia sido validado. Isso transforma um dinode de journal inválido inesperado durante a desmontagem em uma falha no kernel (kernel crash) em vez de uma falha normal na montagem.
[CORREÇÃO]
Substituir a chamada BUG_ON() por WARN_ON() e retornar -EIO. Isso mantém o aviso de invariante para fins de depuração, mas restaura o comportamento original de falhar limpa ou no início (startup) ou no desligamento (shutdown), em vez de causar um pânico do kernel.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.