CVE-2026-93235
NieznaneStreszczenie
W jądrze Linux w systemie plików F2FS wykryto błąd polegający na tym, że przy rozszerzaniu rozmiaru pliku przez nieprzyrównaną granicę EOF dane poza poprzednim EOF w częściowej stronie nie były zerowane. W efekcie po ponownym zamontowaniu lub po odzyskaniu po awarii mogły zostać ujawnione nieaktualne dane z dysku znajdujące się poza poprzednim końcem pliku.
Ocena ryzyka
Może dojść do wycieku danych szczątkowych z dysku (stale dane poza poprzednim EOF) do zawartości pliku widocznej dla użytkownika, co stanowi ryzyko naruszenia poufności. Problem dotyczy głównie środowisk innych niż Android, gdzie zapis bezpośredni przez PBA nie jest ograniczony do pinfile.
Rekomendacja
Zaktualizować jądro Linux do wersji zawierającej poprawkę, a w środowiskach narażonych na ten problem zamontować system plików F2FS z opcją fsync_mode=strict.
Inne podatności w Linux kernel F2FS
Zobacz wszystkie- CVE-2026-89830Nieznane
W jądrze Linux w funkcji __allocate_data_block() systemu plików f2fs, przy alokacji nowego bloku danych najpierw zwiększany jest licznik zajętych bloków (inc_valid_block_count()), a jeśli kolejna operacja f2fs_allocate_data_block() zakończy się błędem, funkcja zwraca błąd bez cofnięcia tego zwiększenia. Powoduje to trwały wyciek licznika poprawnych bloków.
- CVE-2026-89829Wysokie
W jądrze Linux funkcja f2fs_sanity_check_node_footer() nie otrzymuje poprawnej wartości folio->index, przez co sprawdza ten sam nid w nieprawidłowy sposób. Może to prowadzić do błędnej weryfikacji spójności węzłów w systemie plików f2fs.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to zero post-EOF data when extending file size generic/794 4s ... - output mismatch (see /share/git/fstests/results//generic/794.out.bad) --- tests/generic/794.out 2026-06-12 08:46:32.766426241 +0800 +++ /share/git/fstests/results//generic/794.out.bad 2026-07-05 18:32:55.000000000 +0800 @@ -1,4 +1,16 @@ QA output created by 794 append_write +FAIL: non-zero data in gap [4080,4096) after shutdown+remount +000000 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a >ZZZZZZZZZZZZZZZZ< +* +001000 truncate_up ... (Run 'diff -u /share/git/fstests/tests/generic/794.out /share/git/fstests/results//generic/794.out.bad' to see the entire diff) Ran: generic/794 Failures: generic/794 Failed 1 of 1 tests Steps of generic/794: 1. write 4096 bytes to file w/ 0x5a 2. use fiemap to get PBA of first block in file 3. truncate file to 4080 4. umount; write 4096 bytes to file w/ 0x5a directly via PBA; mount 5. extend filesize via a) append 4096 from offset 4096, or b) truncate 8192, or c) fallocate 4096 from offset 4096 6. verify the gap is zeroed in memory [4080,4096) 7. sync range 4096 from offset 4096; shutdown -f (flush meta before shutdown) 8. umount; mount; verify [4080,4096) is zeroed or not. When extending file size (e.g. via truncate, fallocate, or write) across an unaligned EOF boundary, we need to ensure that post-EOF data in the partial page is zeroed out in pagecache and marked dirty, then writeback the cache to persist zeroed data before committing inode w/ updated i_size. This help to prevent stale disk data beyond the previous EOF from being exposed after remounting or crash recovery. Since f2fs is a LFS filesystem, we only support direct write via PBA in pinfile, and pinfile has section-aligned filesize, so in Android, there should no problem, but for other usage in different environment, let's fix this w/ fsync_mode=strict mount option.