CVE-2026-74308 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix kernel BUG in ext4_write_inline_data_end
When the data=journal mount option is used, the ext4_journalled_write_end() function incorrectly calls ext4_write_inline_data_end() without checking if the EXT4_STATE_MAY_INLINE_DATA flag is still set on the inode.
If a previous attempt to convert the inline data to an extent failed (e.g. due to ENOSPC), the EXT4_STATE_MAY_INLINE_DATA flag is cleared, but the EXT4_INODE_INLINE_DATA flag remains set. In this scenario, the next call to ext4_write_begin() will not prepare the inline data xattr for writing, but ext4_journalled_write_end() will incorrectly attempt to write to it, triggering a BUG_ON(pos + len > EXT4_I(inode)->i_inline_size) in ext4_write_inline_data() since i_inline_size was not expanded.
Fix this by ensuring that ext4_journalled_write_end() only calls ext4_write_inline_data_end() if the EXT4_STATE_MAY_INLINE_DATA flag is set, mirroring the behavior of ext4_write_end() and ext4_da_write_end().
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the ext4 filesystem implementation of the linux kernel where a kernel bug occurs during journaling operations with inline data handling. The issue specifically manifests when the data=journal mount option is active, creating a condition where function calls are made without proper state validation. The flaw stems from improper flag checking in the ext4_journalled_write_end() function which directly invokes ext4_write_inline_data_end() without verifying that the EXT4_STATE_MAY_INLINE_DATA flag remains set on the inode.
The technical root cause involves a race condition or state inconsistency where previous operations have already cleared the EXT4_STATE_MAY_INLINE_DATA flag due to failed conversion attempts such as when encountering ENOSPC (error no space left on device) conditions. Despite this flag being cleared, the EXT4_INODE_INLINE_DATA flag persists in its set state, creating a discrepancy that leads to incorrect assumptions about the inode's capability to handle inline data operations. This inconsistency allows the system to proceed with writing to inline data structures that are no longer properly initialized or supported.
When ext4_write_begin() is called subsequently, it correctly recognizes that inline data preparation should not occur due to the cleared flag state, yet ext4_journalled_write_end() ignores this context and attempts to write to the inline data area. This mismatch triggers a kernel BUG_ON assertion failure because the system attempts to write beyond the bounds defined by EXT4_I(inode)->i_inline_size, which was never properly expanded during the earlier failed conversion attempt. The assertion fails with pos + len > EXT4_I(inode)->i_inline_size condition validation, effectively crashing the kernel.
The operational impact of this vulnerability is significant as it represents a kernel panic condition that can lead to system crashes and potential data loss when the journaling filesystem encounters write operations under specific error conditions. This affects systems using ext4 with journaling enabled and particularly impacts workloads that experience storage space constraints during inline data operations. The vulnerability demonstrates a classic case of improper state management in kernel code where flag validation is insufficient, leading to memory access violations.
This issue aligns with CWE-691, which covers inadequate protection of code from incorrect use of state information, and relates to ATT&CK technique T1489 by potentially causing system instability through kernel-level modifications. The fix implements proper flag validation that mirrors the behavior found in similar functions like ext4_write_end() and ext4_da_write_end(), ensuring consistency across the filesystem implementation. This defensive programming approach prevents the execution path that leads to kernel BUG_ON violations, maintaining system stability during error recovery scenarios.
The resolution involves modifying the ext4_journalled_write_end() function to check whether EXT4_STATE_MAY_INLINE_DATA flag is still set before proceeding with inline data operations. This change ensures that the function behaves consistently with other write end handlers in the filesystem implementation and prevents the kernel from attempting to access inline data structures when they are no longer valid for operation. The fix maintains backward compatibility while preventing the specific crash condition that occurs during journaling operations under resource constraint scenarios.
This vulnerability highlights the complexity of maintaining consistent state across multiple kernel subsystems and demonstrates how seemingly minor flag validation issues can lead to catastrophic system failures. The fix represents a standard defensive programming pattern where input validation prevents invalid code paths, similar to practices recommended in secure coding guidelines for operating system development. The solution ensures that filesystem operations remain robust even when previous attempts have failed due to resource constraints or other operational limitations, maintaining overall system reliability and preventing denial of service conditions through kernel-level crashes.