Odebrany

CVE-2026-93235

opublikowano: 24.09.2026, 18:17

modyfikacja: 25.09.2026, 15: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ę:

f2fs: naprawa zerowych danych po EOF podczas zwiększania rozmiaru pliku

generic/794 4s ... - niezgodność wyników (zobacz /share/git/fstests/results//generic/794.out.bad)
--- testy/ogólne/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 @@
Dane wyjściowe kontroli jakości utworzone przez 794
dołącz_zapisz
+FAIL: niezerowe dane w luce [4080,4096) po wyłączeniu i ponownym zamontowaniu
+000000 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a >ZZZZZZZZZZZZZZ<
+*
+001000
obcięcie_up
...
(Uruchom „diff -u /share/git/fstests/tests/generic/794.out /share/git/fstests/results//generic/794.out.bad”, aby zobaczyć całą różnicę)
Uruchomiono: ogólny/794
Awarie: ogólne/794
Nie udało się 1 z 1 testów

Kroki ogólnego/794:
1. zapisz 4096 bajtów do pliku z 0x5a
2. użyj fiemap, aby uzyskać PBA pierwszego bloku w pliku
3. obetnij plik do 4080
4. ilość; zapisz 4096 bajtów do pliku z 0x5a bezpośrednio przez PBA; zamontować
5. rozszerz rozmiar pliku poprzez
a) dodać 4096 z offsetu 4096, lub
b) obciąć 8192, lub
c) fallocate 4096 z offsetu 4096
6. sprawdź, czy luka w pamięci jest wyzerowana [4080,4096)
7. zakres synchronizacji 4096 z offsetem 4096; zamknięcie -f (opróżnij meta przed zamknięciem)
8. ilość; uchwyt; sprawdź, czy [4080,4096) jest wyzerowany, czy nie.

Podczas zwiększania rozmiaru pliku (np. poprzez obcinanie, odwracanie lokalizacji lub zapis) w formacie
niewyrównanej granicy EOF, musimy upewnić się, że dane po EOF są częściowe
strona jest wyzerowana w pagecache i oznaczona jako brudna, a następnie zapisz ponownie pamięć podręczną
utrzymuj zerowane dane przed zatwierdzeniem i-węzła ze zaktualizowanym i_size.

Pomaga to zapobiec ujawnieniu nieaktualnych danych na dysku wykraczających poza poprzedni EOF
po ponownym zamontowaniu lub odzyskaniu po awarii.

Ponieważ f2fs jest systemem plików LFS, obsługujemy tylko bezpośredni zapis poprzez PBA w pliku pin,
a pinfile ma rozmiar pliku dostosowany do sekcji, więc w Androidzie nie powinno być problemu,
ale w przypadku innych zastosowań w innym środowisku naprawmy to za pomocą/fsync_mode=strict
opcja montażu.

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.

>_ 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