Cloudanix VulnDB

CVE-2026-92502

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux filesystem bug can cause scary error messages about lost data during normal shutdowns on certain disk configurations, even though the data is usually safe.

Exploitation
Other
Attacker needs
None
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Stale PAGECACHE_TAG_DIRTY and PAGECACHE_TAG_TOWRITE xarray tags remain on clean folios skipped during writeback in ext4 data=journal mode, allowing the writeback thread to invoke ext4_journal_check_start after the superblock has been remounted read-only and trigger warnings plus inode eviction messages.

Why it matters to the business

Systems using ext4 with journal_data can experience unexpected kernel warnings and data-loss alerts during routine reboots or remounts, increasing operational risk and requiring investigation even when no actual data corruption occurred.

How an attack unfolds

An attacker or benign workload generates heavy random writes under data=journal, then triggers a reboot; the writeback workqueue encounters the read-only superblock while stale tags cause it to attempt journaling on clean folios, surfacing the WARN_ON and subsequent ext4_evict_inode warning.

How to fix it

Apply the upstream fix that clears stale xarray tags for skipped clean folios in mpage_prepare_extent_to_map; update to a kernel containing commit f4a2b42e7891 and the follow-on change described in CVE-2026-92502.

How to confirm the fix worked

After patching, reproduce the fio workload plus reboot sequence and confirm absence of the ext4_journal_check_start WARN_ON and ext4_evict_inode data-loss messages in dmesg.

Typical attack path

  1. Mount ext4 filesystem with data=journal
  2. Run sustained random-write workload
  3. Initiate reboot or remount read-only
  4. Writeback thread processes folios with stale xarray tags
  5. ext4_journal_check_start hits WARN_ON_ONCE(sb_rdonly(sb))
  6. ext4_evict_inode emits data-will-be-lost warning

How to detect it

Search kernel logs for the strings ext4_journal_check_start, ext4_evict_inode, and writepages RDONLY together with dirtytag or towrite indicators; examine dmesg or journalctl around reboot timestamps for the specific WARN_ON and inode number messages.

  • ext4_journal_check_start+0x8b/0xd0
  • EXT4-fs warning (device
  • data will be lost
  • writepages RDONLY nrpages=
  • dirtytag=1 wbtag=0 towrite=1

What your security team should do

  • Prioritize patching ext4 data=journal hosts that perform frequent reboots or large write workloads
  • Add ext4 writeback and journal-related kernel messages to SIEM alerting
  • Consider temporary mitigation by disabling data=journal where journal integrity requirements permit

The record

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.

Affected packages

Ecosystem Package Introduced Fixed