CVE-2026-92502: ext4: clear stale xarray tags on folios skipped during writeback

CVE-2026-92502: ext4: clear stale xarray tags on folios skipped during writeback

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

ext4: clear stale xarray tags on folios skipped during writeback

In data=journal mode, the writeback thread can hit the
WARN_ON_ONCE(sb_rdonly(sb)) in ext4_journal_check_start() while the
superblock is being remounted read-only during reboot:

Workqueue: writeback wb_workfn (flush-253:0)
RIP: 0010:ext4_journal_check_start+0x8b/0xd0
Call Trace:
  __ext4_journal_start_sb+0x3c/0x1e0
  mpage_prepare_extent_to_map+0x4af/0x580
  ext4_do_writepages+0x3c0/0x1080
  ext4_writepages+0xc8/0x1a0
  do_writepages+0xc4/0x180
  __writeback_single_inode+0x45/0x2f0
  writeback_sb_inodes+0x26b/0x5d0
  __writeback_inodes_wb+0x54/0x100
  wb_writeback+0x1ac/0x320
  wb_workfn+0x394/0x470

And followed by the warning:
EXT4-fs warning (device vda1): ext4_evict_inode:195: inode #6263:
comm (sd-umount): data will be lost

This issue is not reproduced every time, but frequently.
The reproduction step is to create a VM with 8 CPUs, 16G memory and
setup data=journal:
sudo tune2fs -o journal_data /dev/vda1
Run fio:
rm -f fiotest
fio --name=fiotest --rw=randwrite --bs=4k --runtime=6 --ioengine=libaio
--iodepth=256 --numjobs=8 --filename=fiotest --filesize=30G
--group_reporting
Reboot the VM, and check the console output from:
virsh console testvm

But there is no dirty inode, folio_clear_dirty_for_io clears PG_dirty
but leaves tags PAGECACHE_TAG_DIRTY and PAGECACHE_TAG_TOWRITE set which
are only cleared by __folio_start_writeback.
In data=journal mode, jbd2 checkpoints the journalled data to its final
location and clears its own dirty flag without touching folio PG_dirty
or xarray dirty flags.
The commit f4a2b42e7891 ("ext4: fix stale xarray tags after writeback")
fixes when PG_dirty is still set but there is no dirty page.
Another case is PG_dirty is cleared, but PAGECACHE_TAG_DIRTY and
PAGECACHE_TAG_TOWRITE is still set. In this case, writeback thread
checks clean folio and skips it in mpage_prepare_extent_to_map:
if (!folio_test_dirty(folio) ||
    ...
        folio_unlcok(folio);
	continue

And never reaches ext4_bio_write_folio where the commit f4a2b42e7891
clears the stale xarray tags. Print debug logs after the filesystem
is remounted read-only:
writepages RDONLY nrpages=2048 dirtytag=1 wbtag=0 towrite=1 sync=0
And all folios are actually clean:
folio idx=3 dirty=0 wb=0 checked=0 dirtybuf=0 jbddirty=0 mapped=1
...

We need to clear the xarray stale tags for such clean folios by
cycling them through writeback in the skip path, the same way
f4a2b42e7891 does in ext4_bio_write_folio.

The Linux kernel CVE team has assigned CVE-2026-92502 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.2 with commit dff4ac75eeeefc4397fe7cf8ce559425bf46b1f7 and fixed in 6.6.157 with commit f82a4929d0ef7ddf254c1c295ec1dfd24094f2de
	Issue introduced in 6.2 with commit dff4ac75eeeefc4397fe7cf8ce559425bf46b1f7 and fixed in 6.12.110 with commit a450ab88bfd57b227d72c7a3faad54d16c3fc099
	Issue introduced in 6.2 with commit dff4ac75eeeefc4397fe7cf8ce559425bf46b1f7 and fixed in 6.18.52 with commit aa0042630b1f7cab735b0a168539281198822586
	Issue introduced in 6.2 with commit dff4ac75eeeefc4397fe7cf8ce559425bf46b1f7 and fixed in 7.2.6 with commit 43ae387c3ae6a11227d096669ddf883e27a39a11
	Issue introduced in 6.2 with commit dff4ac75eeeefc4397fe7cf8ce559425bf46b1f7 and fixed in 7.3-rc1 with commit ec524aae479b4b2078c47492b90ec21200bce434

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-92502
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/ext4/inode.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/f82a4929d0ef7ddf254c1c295ec1dfd24094f2de
	https://git.kernel.org/stable/c/a450ab88bfd57b227d72c7a3faad54d16c3fc099
	https://git.kernel.org/stable/c/aa0042630b1f7cab735b0a168539281198822586
	https://git.kernel.org/stable/c/43ae387c3ae6a11227d096669ddf883e27a39a11
	https://git.kernel.org/stable/c/ec524aae479b4b2078c47492b90ec21200bce434