CVE-2026-92500
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A flaw in how the Linux filesystem handles certain file writes could let one process interfere with another and cause the computer to crash or lose data.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in ext4 write path where concurrent inline-to-extent conversion between write_begin and write_end causes write_end handlers to take the wrong path, dereference NULL folio buffers, or hit a BUG_ON after xattr lock acquisition, resulting in kernel panic or data loss.
Why it matters to the business
Systems running affected kernels may experience sudden crashes or silent data corruption during buffered writes on filesystems using inline data, increasing downtime and risking integrity of user data; low exploitability keeps immediate urgency moderate but still requires patching to avoid operational disruption.
How an attack unfolds
An attacker with local write access triggers rapid page faults or writes that race with ext4_write_begin/ext4_da_write_begin and ext4_page_mkwrite, causing the inline-data state to change after fsdata is prepared but before the write_end decision, leading the kernel into an invalid execution path.
How to fix it
Upgrade to a Linux kernel containing the referenced commit that passes write state via fsdata and replaces the BUG_ON with a safe retry path; rebuild and reboot with the fixed kernel.
How to confirm the fix worked
Confirm the running kernel contains the fsdata-based inline tracking change and that ext4_write_inline_data_end no longer contains the original BUG_ON; exercise concurrent write and page-fault workloads on inline-data files to verify absence of panics.
Typical attack path
- Obtain local unprivileged access on a system using ext4 with inline data enabled
- Perform concurrent buffered writes and mmap faults on the same file to trigger the race window
- Force the kernel through the mismatched write_end path that assumes inline data without allocated buffers
- Trigger NULL dereference or the retained BUG_ON path to crash the system or corrupt data
How to detect it
Review kernel logs for ext4 BUG_ON messages or NULL pointer dereferences in write_end paths; look for repeated page_mkwrite and write_begin activity on the same inode in ftrace or perf traces around crash times.
What your security team should do
- Prioritize kernel updates on all systems using ext4 filesystems within the next maintenance window
- Monitor for kernel oops or ext4-related panics in system logs as an interim detection measure
- Disable inline data (ext4 inode size tuning) only if upgrade timelines cannot be met and workload permits
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|