{"id":"AZL-102053","summary":"CVE-2026-92501 affecting package kernel 6.6.150.1-1","details":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: drain in-flight DIO before buffered write fallback\n\ngeneric/746 started failing intermittently on ext3 (no-extent inodes).\nThe test triggers 'Page cache invalidation failure on direct I/O'\nwarnings and subsequent fsync returns -EIO. Adding a 50ms delay\nbetween ext4_buffered_write_iter() and filemap_write_and_wait_range()\nin ext4_dio_write_iter() makes the race almost always reproducible.\n\nOn no-extent inodes, DIO writes to holes cannot use unwritten extents,\nso ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0.\nThe iomap layer then returns -ENOTBLK, causing fallback to buffered I/O.\n\nThe fallback path in ext4_dio_write_iter() calls\next4_buffered_write_iter() which dirties pages, then does flush and\ninvalidate. However, there's an unprotected window between\next4_buffered_write_iter() returning (with inode lock released) and\nthe subsequent flush+invalidate.\n\nConcurrent async DIO completions from other threads can run\nkiocb_invalidate_post_direct_write() during this window. If pages have\nbeen re-dirtied, post-invalidation finds dirty pages and triggers the\nwarning, setting -EIO in the error sequence.\n\nConsider a file with two 4k extents: [hole][written]. Thread A does\nDIO to the written extent, while thread B does DIO spanning both:\n\n  kworker A (4k DIO, allocated block)    kworker B (8k DIO, fallback)\n  -----------------------------------    ----------------------------\n  inode_lock_shared()                    inode_lock_shared()\n  iomap_dio_rw():                        iomap_dio_rw():\n    kiocb_invalidate_pages -\u003e clean        iomap_begin -\u003e -ENOTBLK\n    submit_bio (async)                     dio-\u003esize = 0\n  inode_unlock_shared()                  inode_unlock_shared()\n\n  [bio pending in block layer]           /* fallback: lock released */\n                                         ext4_buffered_write_iter()\n                                           inode_lock(exclusive)\n                                           generic_perform_write()\n                                             -\u003e dirty pages [0, 8k]\n                                           inode_unlock(exclusive)\n\n                                         /* pages dirty, no lock */\n  [bio completes]                        filemap_write_and_wait_range()\n  iomap_dio_complete()                     -\u003e flush dirty pages\n    kiocb_invalidate_post_direct_write() invalidate_mapping_pages()\n      invalidate_inode_pages2_range()\n      -\u003e finds dirty page!\n      -\u003e dio_warn_stale_pagecache()\n      -\u003e errseq_set(-EIO)\n\nThis issue can be triggered through normal I/O paths, not just\nintentionally overlapping DIO writes from userspace. For example,\ngeneric/746 uses a loop device where multiple kworkers issue concurrent\nI/O to the backing file. Additionally, when block_size \u003c folio_size,\nnon-overlapping DIO writes that share a large folio can also trigger\nthe race.\n\nAdd inode_dio_wait() in ext4_buffered_write_iter() before\next4_write_checks() to drain all in-flight DIO. This ensures that\nall DIO clears existing pages before submitting IO (via\nkiocb_invalidate_pages()), all BIO waits for all DIO to complete\n(via inode_dio_wait()), and ext4_write_checks() observes the inode\nsize after all completed DIO so that ext4_block_zero_eof() does not\nrace with in-flight DIO, thus eliminating the race.","modified":"2026-09-18T14:16:30.089221683Z","published":"2026-09-17T17:17:52Z","upstream":["CVE-2026-92501"],"references":[{"type":"WEB","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-92501"}],"affected":[{"package":{"name":"kernel","ecosystem":"Azure Linux:3","purl":"pkg:rpm/azure-linux/kernel"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"6.6.150.1-1"}]}],"database_specific":{"source":"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-102053.json"}}],"schema_version":"1.9.0"}