CVE-2026-93258 in Linuxinfo

Summary

by MITRE • 09/24/2026

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: do not use make_bad_inode() in ocfs2_read_inode_block_full()

This reverts commit 58b6fcd2ab34 ("ocfs2: mark inode bad upon validation failure during read").

Since 'make_bad_inode()' resets inode type to S_IFREG, doing this for directory inode during active VFS lookup is likely to confuse the latter, including VFS_BUG_ON_INODE() triggered in this case.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 09/24/2026

The vulnerability addressed involves a regression introduced in the Linux kernel's Oracle Cluster File System version 2 implementation, specifically within the ocfs2_read_inode_block_full function. The root cause of this issue stems from an incorrect application of the make_bad_inode helper routine during inode validation failures. When reading an inode block, if the system encounters data that fails integrity or format checks, it previously invoked make_bad_inode to mark the corrupted inode as invalid. However, this approach is fundamentally flawed because make_bad_inode unconditionally resets the inode type field to S_IFREG, which represents a regular file in Unix-like operating systems. This action disregards the actual nature of the inode being processed, leading to severe inconsistencies within the Virtual File System layer when the affected inode corresponds to a directory rather than a regular file.

The operational impact of this flaw is significant for system stability and data integrity during active filesystem operations. When VFS_BUG_ON_INODE triggers due to the mismatched inode type, it indicates that the kernel has detected an internal state inconsistency that violates expected invariants. Specifically, if a directory inode is marked as a regular file via make_bad_inode while the Virtual File System is actively performing lookups or traversals on that path, the VFS layer encounters conflicting metadata. This confusion can lead to kernel panics, unexpected process terminations, or undefined behavior during critical filesystem operations such as mkdir, rmdir, or directory traversal. The presence of a BUG_ON assertion suggests that this condition was intended to be caught early but resulted in a crash rather than graceful error handling due to the improper state transition applied by the previous commit.

This issue is classified under CWE-674, which covers Uncontrolledly Affected Resource Consumption, as well as CWE-20, Improper Input Validation, since the root cause lies in failing to properly validate and handle corrupted or malformed inode data before applying structural changes that assume a specific file type. From an ATT&CK perspective, while this is primarily a stability issue rather than a direct exploitation vector for privilege escalation, it relates to T1496, Resource Hijacking, if the resulting denial of service impacts system availability. The vulnerability highlights the critical importance of context-aware error handling in kernel development, where assumptions about object types must be strictly validated before state modifications are applied.

To mitigate this risk, the resolution involves reverting commit 58b6fcd2ab34 and replacing the use of make_bad_inode with a more appropriate error handling mechanism that does not alter the inode type incorrectly. Developers should ensure that validation failures during inode reads result in returning an error code to the caller rather than modifying the inode structure itself, allowing higher-level filesystem logic to handle the corruption gracefully. System administrators relying on OCFS2 environments must apply this kernel patch immediately to prevent potential crashes during directory operations involving potentially corrupted metadata. Regular auditing of filesystem integrity and ensuring that backup systems do not introduce malformed inodes into active clusters are also recommended defensive measures to reduce the likelihood of triggering such validation failures in production environments.

Responsible

Linux

Reservation

09/17/2026

Disclosure

09/24/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you need the next level of professionalism?

Upgrade your account now!