ext4: use fsdata to track inline data write state and fix race
Summary
| CVE | CVE-2026-92500 |
|---|---|
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-09-17 17:17:52 UTC |
| Updated | 2026-09-17 17:17:52 UTC |
| Description | 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. |
Risk And Classification
EPSS: 0.001760000 probability, percentile 0.074060000 (date 2026-09-18)
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Linux | Linux | affected 3fdcfb668fd78ec92d9bc2daddf1d41e2a8a30bb bd8d74bd46d09905164255b8635fa58b45f41068 git | Not specified |
| CNA | Linux | Linux | affected 3fdcfb668fd78ec92d9bc2daddf1d41e2a8a30bb 439aedfd7ae868d1d7b4930afe66091cb979cd5c git | Not specified |
| CNA | Linux | Linux | affected 3fdcfb668fd78ec92d9bc2daddf1d41e2a8a30bb 7edbb323bab2b2a609016014caafdb651c898249 git | Not specified |
| CNA | Linux | Linux | affected 3.8 | Not specified |
| CNA | Linux | Linux | unaffected 3.8 semver | Not specified |
| CNA | Linux | Linux | unaffected 6.18.52 6.18.* semver | Not specified |
| CNA | Linux | Linux | unaffected 7.2.6 7.2.* semver | Not specified |
| CNA | Linux | Linux | unaffected 7.3-rc1 * original_commit_for_fix | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| git.kernel.org/stable/c/439aedfd7ae868d1d7b4930afe66091cb979cd5c | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| git.kernel.org/stable/c/7edbb323bab2b2a609016014caafdb651c898249 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| git.kernel.org/stable/c/bd8d74bd46d09905164255b8635fa58b45f41068 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.