UBUNTU-CVE-2026-92500: Null Pointer Dereference

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.