CVE-2026-92500

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 (ext4_has_inline_data(inode)

and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the

write_end handlers, use the fsdata parameter of the address space

operations to explicitly pass down the state in which write_begin

prepared the write.

A concurrent thread (such as ext4_page_mkwrite()) can convert the

inline data to an extent between write_begin and write_end. If this

happens, the write_end handlers would previously miss the inline

write_end path and fall through to extent-based write_end logic.

However, since block buffers were never allocated in write_begin,

this resulted in NULL pointer dereferences or data loss because

folio_buffers(folio) was NULL.

Define EXT4_WRITE_DATA_INLINE (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) ext4_write_begin() and ext4_da_write_begin() set the

EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline

write is successfully prepared.

2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit

to safely handle VFS retries (where generic_perform_write() bypasses

the fsdata initialization on its retry jump).

3) The write_end handlers perform a bitwise AND to check if the

EXT4_WRITE_DATA_INLINE bit is set and invoke the inline write_end

helper accordingly.

Furthermore, during a buffered write, ext4_write_inline_data_end()

acquires the xattr lock after preparing the write. If a concurrent

page fault (ext4_page_mkwrite()) converts the inline data to an extent

after the write_end handlers check the state but before

ext4_write_inline_data_end() acquires the xattr write lock, the

subsequent check will trigger a kernel panic via

BUG_ON(!ext4_has_inline_data(inode)).

To keep git history working and bisectability clean, replace the

BUG_ON check in ext4_write_inline_data_end() 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.