CVE-2026-92501ext4: drain in-flight DIO before buffered write fallback
- —Not scoredno CVSS score yet
- 0.18%Exploitation in 30 daysEPSS · top 93% of all CVEs
- NoKnown exploitednot in CISA's KEV catalog
- NonePublic exploitsnone known yet
Description
In the Linux kernel, the following vulnerability has been resolved: ext4: drain in-flight DIO before buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race.
Timeline
ID reserved
By Linux
- 1 day later
· 1 day later
Published
- 32 days later
· 32 days later
Record updated
Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.
Scores
No CVSS score yet: neither the CNA, CISA nor NVD has scored this CVE. NVD status: Received.
- EPSS (exploitation in 30 days)
- 0.18% · top 93% of all CVEs (14 Nov 2026)
The list uses the assigner's score when there is one, then CISA's, then NVD's: Not scored.
Affected products
- affected 378f32bab3714f04c4e0c3aee4129f6703805550 – < fd7e0dab20837b9ea1eeef7c26f78ace8ac8258c
- affected 378f32bab3714f04c4e0c3aee4129f6703805550 – < f0af3ae09fb72382da1a5371bf6761b0264668e4
- affected 378f32bab3714f04c4e0c3aee4129f6703805550 – < 7341e234927ff215f1d5d0bcfe04b74f53af378d
- affected 378f32bab3714f04c4e0c3aee4129f6703805550 – < 74eee4ff9698a65b2e6e15dac0e50d6526ad5f20
- affected 378f32bab3714f04c4e0c3aee4129f6703805550 – < d47cdadd6e49023f7ee248048463807f1214f1ee
- affected 378f32bab3714f04c4e0c3aee4129f6703805550 – < 4e4e3eec506247c8f8bd8aaa1eb25e67016681a5
- affected 378f32bab3714f04c4e0c3aee4129f6703805550 – < 9fd3ffc3c51c9deaba99bd7b338fff2d08f52416
- affected 378f32bab3714f04c4e0c3aee4129f6703805550 – < 15cdefd0c0522f9d5e12d947fa04f4c11649b699
- affected 5.5
- unaffected < 5.5
- unaffected 5.10.270 – ≤ 5.10.*
- unaffected 5.15.221 – ≤ 5.15.*
- unaffected 6.1.188 – ≤ 6.1.*
- unaffected 6.6.157 – ≤ 6.6.*
- unaffected 6.12.110 – ≤ 6.12.*
- unaffected 6.18.52 – ≤ 6.18.*
- unaffected 7.2.6 – ≤ 7.2.*
- unaffected 7.3 – ≤ *
References
References8
- https://git.kernel.org/stable/c/fd7e0dab20837b9ea1eeef7c26f78ace8ac8258c (opens in a new tab)
- https://git.kernel.org/stable/c/f0af3ae09fb72382da1a5371bf6761b0264668e4 (opens in a new tab)
- https://git.kernel.org/stable/c/7341e234927ff215f1d5d0bcfe04b74f53af378d (opens in a new tab)
- https://git.kernel.org/stable/c/74eee4ff9698a65b2e6e15dac0e50d6526ad5f20 (opens in a new tab)
- https://git.kernel.org/stable/c/d47cdadd6e49023f7ee248048463807f1214f1ee (opens in a new tab)
- https://git.kernel.org/stable/c/4e4e3eec506247c8f8bd8aaa1eb25e67016681a5 (opens in a new tab)
- https://git.kernel.org/stable/c/9fd3ffc3c51c9deaba99bd7b338fff2d08f52416 (opens in a new tab)
- https://git.kernel.org/stable/c/15cdefd0c0522f9d5e12d947fa04f4c11649b699 (opens in a new tab)
Sources
The same CVE in the primary databases and aggregators, to check against.
- CVE.org record (opens in a new tab)
- CVE List JSON (GitHub) (opens in a new tab)
- NVD (opens in a new tab)
- FIRST EPSS (opens in a new tab)
- EUVD EUVD-2026-82122 (opens in a new tab)
- OSV.dev (opens in a new tab)
- GitHub Advisories (opens in a new tab)
- CIRCL Vulnerability-Lookup (opens in a new tab)
Badge for a README or a ticket
[](https://cveledger.app/cve/CVE-2026-92501)Record last updated .