CVE-2026-92502: ext4: clear stale xarray tags on folios skipped during writeback
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 WARNONONCE(sbrdonly(sb)) in ext4journalcheckstart() while the superblock is being remounted read-only during reboot:
Workqueue: writeback wbworkfn (flush-253:0) RIP: 0010:ext4journalcheckstart+0x8b/0xd0 Call Trace: ext4journalstartsb+0x3c/0x1e0 mpageprepareextenttomap+0x4af/0x580 ext4dowritepages+0x3c0/0x1080 ext4writepages+0xc8/0x1a0 dowritepages+0xc4/0x180 writebacksingleinode+0x45/0x2f0 writebacksbinodes+0x26b/0x5d0 writebackinodeswb+0x54/0x100 wbwriteback+0x1ac/0x320 wbworkfn+0x394/0x470
And followed by the warning: EXT4-fs warning (device vda1): ext4evictinode: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 journaldata /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 --groupreporting Reboot the VM, and check the console output from: virsh console testvm
But there is no dirty inode, foliocleardirtyforio clears PGdirty but leaves tags PAGECACHETAGDIRTY and PAGECACHETAGTOWRITE set which are only cleared by foliostartwriteback. In data=journal mode, jbd2 checkpoints the journalled data to its final location and clears its own dirty flag without touching folio PGdirty or xarray dirty flags. The commit f4a2b42e7891 ("ext4: fix stale xarray tags after writeback") fixes when PGdirty is still set but there is no dirty page. Another case is PGdirty is cleared, but PAGECACHETAGDIRTY and PAGECACHETAGTOWRITE is still set. In this case, writeback thread checks clean folio and skips it in mpageprepareextenttomap: if (!foliotestdirty(folio) || ... foliounlcok(folio); continue
And never reaches ext4biowritefolio 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 ext4biowritefolio.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-aws-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1066.69~22.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1070.78~22.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1068.75~22.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1070.78~22.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1066.67~22.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-146.146.1~22.04.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1064.67~22.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-146.146~22.04.1 - Upgrade
Upgrade
ubuntu/linux-realtime-6.8to a version that resolves this vulnerability.Fixed in 6.8.1-1061.62~22.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 6.8.0-146.146 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 6.8.0-1066.69 - Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 6.8.0-1070.78 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 6.8.0-1068.75 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 6.8.0-1070.78 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 6.8.0-1065.73 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 6.8.0-1051.55 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 6.8.0-1066.67 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-146.146.1 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 6.8.0-1064.67 - Upgrade
Upgrade
ubuntu/linux-nvidia-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-1064.67.1 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 6.8.0-1063.66 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 6.8.0-1032.37 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 6.8.1-1061.62 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1066.69+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1069.77+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-146.146+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1070.78+fips1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
Linux kernel (ext4)to a version that resolves this vulnerability.Patch f4a2b42e7891
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using an ext4 filesystem mounted in data=journal mode are implicated. The failure occurs when writeback is active while the filesystem is being remounted read-only during reboot.
What workload makes the problem more likely to occur?
The issue is reported as intermittent but frequent under heavy concurrent random-write activity. The provided reproduction uses fio with eight jobs, 4 KB random writes, and an I/O depth of 256 while data=journal mode is enabled.
How can administrators tell whether a system has encountered it?
Kernel logs may show a WARN_ON_ONCE in ext4_journal_check_start() from the writeback worker during a read-only remount. A subsequent ext4_evict_inode warning stating that data will be lost is also an indicator.