Odebrany

CVE-2026-92502

opublikowano: 17.09.2026, 19:17

modyfikacja: 17.09.2026, 19:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

ext4: usuń nieaktualne znaczniki xarray na folio pominięte podczas zapisywania zwrotnego

W trybie data=journal wątek zapisu zwrotnego może trafić do
WARN_ON_ONCE(sb_rdonly(sb)) w ext4_journal_check_start(), podczas gdy
superblok jest ponownie montowany w trybie tylko do odczytu podczas ponownego uruchamiania:

Kolejka robocza: zapis zwrotny wb_workfn (flush-253:0)
RIP: 0010:ext4_journal_check_start+0x8b/0xd0
Zadzwoń do śledzenia:
__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

A następnie ostrzeżenie:
Ostrzeżenie EXT4-fs (urządzenie vda1): ext4_evict_inode:195: i-węzeł #6263:
comm (sd-umount): dane zostaną utracone

Ten problem nie występuje za każdym razem, ale często.
Etap reprodukcji polega na utworzeniu maszyny wirtualnej z 8 procesorami, pamięcią 16 GB i
dane konfiguracyjne=dziennik:
sudo tune2fs -o dane_dziennika /dev/vda1
Uruchom fio:
rm -f najsilniejszy
fio --name=fiotest --rw=randwrite --bs=4k --runtime=6 --ioengine=libaio
--iogłębi=256 --numjobs=8 --filename=fiotest --filesize=30G
--raportowanie_grupowe
Uruchom ponownie maszynę wirtualną i sprawdź dane wyjściowe konsoli z:
test konsoli virsh

Ale nie ma brudnego i-węzła, folio_clear_dirty_for_io czyści PG_dirty
ale pozostawia ustawione znaczniki PAGECACHE_TAG_DIRTY i PAGECACHE_TAG_TOWRITE
są usuwane tylko przez __folio_start_writeback.
W trybie data=journal jbd2 umieszcza zapisane w dzienniku dane w postaci końcowej
lokalizację i czyści własną flagę brudu bez dotykania folio PG_dirty
lub xarray brudne flagi.
Zatwierdzenie f4a2b42e7891 („ext4: napraw nieaktualne tagi xarray po zapisie zwrotnym”)
naprawiono sytuację, gdy PG_dirty jest nadal ustawiony, ale nie ma brudnej strony.
Innym przypadkiem jest wyczyszczenie PG_dirty, ale PAGECACHE_TAG_DIRTY i
PAGECACHE_TAG_TOWRITE jest nadal ustawiony. W tym przypadku wątek zapisu zwrotnego
sprawdza czyste folio i pomija je w mpage_prepare_extent_to_map:
if (!folio_test_dirty(folio) ||
...
folio_unlcok(folio);
kontynuuj

I nigdy nie dociera do ext4_bio_write_folio, gdzie zatwierdzenie f4a2b42e7891
usuwa nieaktualne znaczniki xarray. Wydrukuj dzienniki debugowania po systemie plików
jest ponownie montowany w trybie tylko do odczytu:
writepages RDONLY nrpages=2048 dirtytag=1 wbtag=0 towrite=1 sync=0
Wszystkie folio są właściwie czyste:
folio idx=3 brudne=0 wb=0 zaznaczone=0 brudnebuf=0 jbddirty=0 zmapowane=1
...

Musimy wyczyścić nieaktualne znaczniki xarray dla takich czystych folio
przełączanie ich cyklicznie przez zapisywanie zwrotne w ścieżce pomijania w ten sam sposób
f4a2b42e7891 robi w ext4_bio_write_folio.

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.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve