Evidence-led vulnerability intelligence · 2026-08-28 13:46 IST

CVE-2026-80644

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.

UNRATED · N/ALinux

Executive briefing

The source record describes: 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. The practical risk depends on whether an affected product/version is present, reachable and configured in an exploitable way. Review the affected-product evidence and linked vendor advisories before assigning exposure status.

Assessment: Potential exposure only — validate the installed product, exact version, configuration and vendor applicability before treating an asset as confirmed vulnerable.

Evidence confidence: Limited Evidence-derived, not an exploitability verdict

Severity & attack characteristics

N/A / 10 ·

CVSS vector:

No CVSS vector is currently available in the source record.

Technical explanation & impact

The technical mechanism is not expanded beyond the source description unless a referenced advisory supplies additional evidence. Read the linked vendor/CERT advisories for root-cause detail.

Potential impact must be interpreted from the published CVSS impact metrics and the affected component. A CVSS impact score is not proof that a particular asset is exploitable.

Affected products and versions

NVD has not supplied machine-readable vulnerable CPE product/version entries for this CVE. This is an information gap, not proof that no products are affected. Check the vendor advisory references below.

Remediation & validation

Identify exposure by comparing the affected product and version ranges with your asset inventory, SBOM and externally exposed services.
Review the linked vendor security advisory or patch notes. Upgrade to a vendor-confirmed fixed release; do not infer a fixed version from the CVE description.
Until patched, consider restricting network access or disabling the affected feature where operationally safe. These are temporary controls, not a substitute for a vendor fix.
Validate the remediation with a version check and vulnerability rescan, then retain change evidence.

No fixed version is displayed unless it is explicitly established by a vendor advisory. Follow the vendor's release notes for exact product and branch applicability.

Vendor advisories, patches & exploit references

https://git.kernel.org/stable/c/12c32a7350b670aaaaf2e01583d8648ec0c9755c REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/3852478d34c7baa490ba9c7374ee901a56eea577 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/5b33f99f3e48465bd93219495381a5aef4fa967f REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/86509c5296fe46ad6bcdd83931a53c2c6b7913a8 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/a06eec15596e5801bad59ad16cd2bf4f0fa839a1 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/b460f8d01a12061853d02c8fb693fb42450acd7d REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/bf1d59cf2ac8a1730607ebaa0bc0dc6d00f197d0 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/c0438198c28b1d22c272751af5e717c11d9fa8dd VENDOR 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Information gaps & confidence notes

These gaps indicate missing source data. CVE Watch does not fill them with guessed product, exploit or patch details.

NVD does not currently provide machine-readable vulnerable CPE product/version entries for this record.
No CVSS vector is currently available in the source record.
No CWE classification is currently available.

Last enrichment: 2026-11-07T16:58:32+00:00 · Source last modified: 2026-11-06T17:19:55.730

Open NVD record ← Back to CVE Watch