CVE-2026-80644 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: don't BUG_ON an invalid journal dinode
[BUG]
A fuzzed OCFS2 image can corrupt the current slot journal dinode while mount is still in progress. The mount path first reports the invalid journal block and then crashes in 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 ...
[CAUSE]
ocfs2_journal_toggle_dirty() used to return -EIO when journal->j_bh no longer contained a valid dinode, because the startup and shutdown paths already handled that failure. Commit 10995aa2451a ("ocfs2: Morph the haphazard OCFS2_IS_VALID_DINODE() checks.") changed the check to a BUG_ON() under the assumption that the journal dinode had already been validated. That turns an unexpected invalid journal dinode during mount teardown into a kernel crash instead of a normal mount failure.
[FIX]
Replace the BUG_ON() with WARN_ON() and return -EIO. This keeps the invariant warning for debugging, but restores the original behavior of failing startup or shutdown cleanly instead of panicking the kernel.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in the Linux kernel's OCFS2 filesystem driver represents a critical flaw in error handling during volume initialization and teardown sequences. Specifically, this issue manifests when an attacker provides a maliciously crafted or corrupted OCFS2 image to the system mount operation. During the mounting process, the kernel attempts to validate various metadata structures, including the journal dinode which is essential for maintaining filesystem consistency and recovery capabilities. When the fuzzed image contains an invalid journal dinode, the initial validation logic correctly identifies this anomaly. However, instead of gracefully aborting the mount operation with a standard input/output error code, the system proceeds into shutdown routines that rely on assumptions about data integrity that are no longer valid in this corrupted state.
The root cause lies in a regression introduced by commit 10995aa2451a, which aimed to streamline and consolidate checks for dinode validity within the OCFS2 codebase. Previously, the function ocfs2_journal_toggle_dirty would return an -EIO error if it detected that the journal block did not contain a valid dinode. This behavior was intentional because both the startup and shutdown paths were designed to handle such failures gracefully by terminating the mount process without crashing the kernel. The aforementioned commit replaced these explicit checks with a BUG_ON macro, operating under the incorrect assumption that prior validation steps had already guaranteed the presence of a valid journal dinode. Consequently, when an invalid dinode is encountered during the teardown phase triggered by a failed or interrupted mount attempt, the code triggers a fatal kernel panic rather than returning an error to userspace.
From a technical perspective, this flaw allows for a local denial-of-service attack against systems running vulnerable versions of the Linux kernel with OCFS2 support enabled. An attacker who has access to block devices or can influence filesystem images mounted by privileged processes can trigger this condition simply by attempting to mount a corrupted image. The resulting crash results in an Oops error, specifically involving an invalid opcode at fs/ocfs2/journal.c:1034 within the ocfs2_journal_toggle_dirty function. This leads to system instability and potential data loss if critical operations were in progress when the panic occurred. While this vulnerability does not directly allow for arbitrary code execution or privilege escalation due to its nature as a crash, it significantly impacts availability, which is a core component of security triage alongside confidentiality and integrity.
In terms of industry standard classifications, this issue aligns with CWE-617: Reachable Assertion, where an assertion condition that should never be false becomes reachable due to improper input validation or state management errors. Furthermore, from the perspective of the MITRE ATT&CK framework, this vulnerability facilitates Local Denial of Service (T1499), as it enables a local actor to disrupt service availability by crashing the operating system kernel through malformed filesystem inputs. The attack vector is primarily local and requires physical or logical access to mount block devices, placing it in the lower complexity tier for exploitation but with high impact on system stability.
The resolution involves replacing the BUG_ON macro with WARN_ON while ensuring that the function returns -EIO upon detecting an invalid journal dinode during shutdown operations. This change preserves the diagnostic value of logging a warning message for debugging purposes without halting kernel execution. By restoring the original behavior where such errors result in clean failure rather than panic, the system maintains resilience against malformed inputs. Administrators and developers should ensure that OCFS2 implementations properly validate all metadata structures before proceeding with operations that assume their validity, particularly during initialization and cleanup phases. Mitigation strategies include applying the kernel patch that corrects this logic error and implementing strict input validation for any filesystem images mounted on production systems to prevent corrupted data from reaching critical subsystem paths.