CVE-2026-92500: ext4: use fsdata to track inline data write state and fix race
In the Linux kernel, the following vulnerability has been resolved:
ext4: use fsdata to track inline data write state and fix race
Instead of checking the live inode state (ext4hasinlinedata(inode) and ext4testinodestate(inode, EXT4STATEMAYINLINEDATA)) in the writeend handlers, use the fsdata parameter of the address space operations to explicitly pass down the state in which writebegin prepared the write.
A concurrent thread (such as ext4pagemkwrite()) can convert the inline data to an extent between writebegin and writeend. If this happens, the writeend handlers would previously miss the inline writeend path and fall through to extent-based writeend logic. However, since block buffers were never allocated in writebegin, this resulted in NULL pointer dereferences or data loss because foliobuffers(folio) was NULL.
Define EXT4WRITEDATAINLINE (4) as a bit flag (Bit 2), treating fsdata as bitwise flags rather than mutually exclusive enums to keep states of the write path independent. Communicate this state via fsdata: 1) ext4writebegin() and ext4dawritebegin() set the EXT4WRITEDATAINLINE bit in fsdata via bitwise OR when an inline write is successfully prepared. 2) On entry, ext4writebegin() clears the EXT4WRITEDATAINLINE bit to safely handle VFS retries (where genericperformwrite() bypasses the fsdata initialization on its retry jump). 3) The writeend handlers perform a bitwise AND to check if the EXT4WRITEDATAINLINE bit is set and invoke the inline writeend helper accordingly.
Furthermore, during a buffered write, ext4writeinlinedataend() acquires the xattr lock after preparing the write. If a concurrent page fault (ext4pagemkwrite()) converts the inline data to an extent after the writeend handlers check the state but before ext4writeinlinedataend() acquires the xattr write lock, the subsequent check will trigger a kernel panic via BUGON(!ext4hasinlinedata(inode)).
To keep git history working and bisectability clean, replace the BUGON check in ext4writeinlinedataend() with a graceful error- handling retry path in this same commit. If the inline data is cleared after locking the xattr, we safely release all resources (releasing iloc.bh, unlocking/putting the folio, stopping the active journal transaction handle) and return 0 (VFS retry) to let the generic write path retry the operation safely.
Event History
Frequently Asked Questions
What conditions are needed to trigger the issue?
The race requires a write that was prepared for inline data, followed by a concurrent operation such as ext4_page_mkwrite() that converts the inode's inline data to extents before write_end runs. The affected write_end path can then use extent-based handling despite block buffers not having been allocated.
What can happen if the race is triggered?
The described outcomes are a NULL pointer dereference because folio_buffers(folio) is NULL, or data loss. The vulnerability is categorized as a null pointer dereference.
How can I determine whether a system may be affected?
Review the Linux kernel's ext4 write paths for the referenced fix: write_begin must communicate the inline-write state through fsdata, and write_end must use that passed state rather than rechecking the live inode inline-data state. Systems with ext4 inline-data writes and concurrent operations that can convert inline data to extents are the relevant scenario.
What should be prioritized for remediation?
Apply a Linux kernel update containing the referenced ext4 changes. The fix preserves the write_begin inline-data state in fsdata using the EXT4_WRITE_DATA_INLINE flag, preventing write_end from incorrectly switching to extent-based handling after a concurrent conversion.