UBUNTU-CVE-2026-92502: Medium severity ubuntu/linux-hwe-edge vulnerability
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
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 to a fixed release to a version that resolves this vulnerability.
Patch f4a2b42e7891
Event History
Frequently Asked Questions
Which Ubuntu kernel packages are identified as affected?
The listed packages are ubuntu/linux-riscv, ubuntu/linux-realtime, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-azure-fde, ubuntu/linux-gke, ubuntu/linux-hwe-edge, and ubuntu/linux-gkeop.
What conditions are involved in triggering the issue?
The reported scenario uses an ext4 filesystem mounted with data=journal mode, active writeback, and a remount to read-only during reboot. The issue was reproduced frequently, but not on every attempt, under concurrent random-write I/O.
How might administrators recognize that the issue occurred?
Kernel logs may show a WARN_ON_ONCE in ext4_journal_check_start() from the writeback worker while the superblock is read-only. This can be followed by an EXT4-fs warning from ext4_evict_inode stating that data will be lost.