In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ext4: clear stale xarray tags on folios skipped during writeback<\/p>\n
In data=journal mode, the writeback thread can hit the
\nWARN_ON_ONCE(sb_rdonly(sb)) in ext4_journal_check_start() while the
\nsuperblock is being remounted read-only during reboot:<\/p>\n
Workqueue: writeback wb_workfn (flush-253:0)
\nRIP: 0010:ext4_journal_check_start+0x8b\/0xd0
\nCall Trace:
\n __ext4_journal_start_sb+0x3c\/0x1e0
\n mpage_prepare_extent_to_map+0x4af\/0x580
\n ext4_do_writepages+0x3c0\/0x1080
\n ext4_writepages+0xc8\/0x1a0
\n do_writepages+0xc4\/0x180
\n __writeback_single_inode+0x45\/0x2f0
\n writeback_sb_inodes+0x26b\/0x5d0
\n __writeback_inodes_wb+0x54\/0x100
\n wb_writeback+0x1ac\/0x320
\n wb_workfn+0x394\/0x470<\/p>\n
And followed by the warning:
\nEXT4-fs warning (device vda1): ext4_evict_inode:195: inode #6263:
\ncomm (sd-umount): data will be lost<\/p>\n
This issue is not reproduced every time, but frequently.
\nThe reproduction step is to create a VM with 8 CPUs, 16G memory and
\nsetup data=journal:
\nsudo tune2fs -o journal_data \/dev\/vda1
\nRun fio:
\nrm -f fiotest
\nfio –name=fiotest –rw=randwrite –bs=4k –runtime=6 –ioengine=libaio
\n–iodepth=256 –numjobs=8 –filename=fiotest –filesize=30G
\n–group_reporting
\nReboot the VM, and check the console output from:
\nvirsh console testvm<\/p>\n
But there is no dirty inode, folio_clear_dirty_for_io clears PG_dirty
\nbut leaves tags PAGECACHE_TAG_DIRTY and PAGECACHE_TAG_TOWRITE set which
\nare only cleared by __folio_start_writeback.
\nIn data=journal mode, jbd2 checkpoints the journalled data to its final
\nlocation and clears its own dirty flag without touching folio PG_dirty
\nor xarray dirty flags.
\nThe commit f4a2b42e7891 (“ext4: fix stale xarray tags after writeback”)
\nfixes when PG_dirty is still set but there is no dirty page.
\nAnother case is PG_dirty is cleared, but PAGECACHE_TAG_DIRTY and
\nPAGECACHE_TAG_TOWRITE is still set. In this case, writeback thread
\nchecks clean folio and skips it in mpage_prepare_extent_to_map:
\nif (!folio_test_dirty(folio) ||
\n …
\n folio_unlcok(folio);
\n\tcontinue<\/p>\n
And never reaches ext4_bio_write_folio where the commit f4a2b42e7891
\nclears the stale xarray tags. Print debug logs after the filesystem
\nis remounted read-only:
\nwritepages RDONLY nrpages=2048 dirtytag=1 wbtag=0 towrite=1 sync=0
\nAnd all folios are actually clean:
\nfolio idx=3 dirty=0 wb=0 checked=0 dirtybuf=0 jbddirty=0 mapped=1
\n…<\/p>\n
We need to clear the xarray stale tags for such clean folios by
\ncycling them through writeback in the skip path, the same way
\nf4a2b42e7891 does in ext4_bio_write_folio.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ext4: clear stale xarray tags on folios skipped during writeback<\/p>\n
In data=journal mode, the writeback thread can hit the
\nWARN_ON_ON<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-25871","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/25871","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=25871"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=25871"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=25871"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}