Odebrany

CVE-2026-89772

opublikowano: 11.09.2026, 22:20

modyfikacja: 11.09.2026, 22:20

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ę:

btrfs: folio chroniące przed zapisem podczas zapisywania zwrotnego danych

zatwierdzenie 095be159f3eb („btrfs: ujednolicenie usuwania brudnej flagi folio”) zastąpiono
wywołanie folio_clear_dirty_for_io() w require_write_cache_pages() z
zwykła kontrola folio_test_dirty(). Oprócz usunięcia brudnej flagi,
folio_clear_dirty_for_io() wywołuje także folio_mkclean(), która chroni przed zapisem
udostępnione PTE mmap mapujące folio. Pamiętaj, że nadal dzwonimy
folio_clear_dirty_for_io() później w Submit_one_sector(), kiedy wyczyścimy
brudny w ostatnim sektorze folio (jedyny sektor dla nie-podstrony
przypadki). Ale straciliśmy to wczesne wywołanie w require_write_cache_pages().

Bez dodatkowej ochrony przed zapisem proces z plikiem mmap-ed może
modyfikować sektor podczas jego używania przez zapisywanie zwrotne w taki sposób, że
oczekuje stabilnego folio (sumowanie kontrolne, kompresja, kopiowanie itp.)
bez zarzutów, co objawia się garścią konkretnych błędów.

1. W przypadku dużych folio lub sektorów podstron istnieje możliwość przesłania biografii
co nie obejmuje całego folio. Kiedy to nastąpi, będziemy mieli
bio w locie po folio, do którego *nie* zadzwoniliśmy
folio_clear_dirty_for_io() włączone. Jeśli zadanie z istniejącym plikiem PTE z wersją mmap
pisze (bez błędów..) w tym oknie, może to skutkować
korupcja. Jeśli zapis nadejdzie podczas sumowania kontrolnego lub samego zapisu
trwa, może to skutkować nieprawidłową sumą kontrolną i późniejszym uszkodzeniem
raporty o przeczytaniu. Jeśli zapis nastąpi po zakończeniu sumowania kontrolnego/zapisu
ale zanim ostatni brudny sektor zostanie wyczyszczony, zapis jest obecny
w pamięci podręcznej strony, ale nie ma to wpływu na brudne śledzenie i zostanie utracone
kiedy folio jest całkowicie ukończone i przesyłane, a brudny kawałek
jest wyczyszczony. Powoduje to utratę zapisu, nawet jeśli zostanie wywołana funkcja fsync().

2. W przypadku zgłoszeń strefowych, które są dokonywane partiami oddzielnie od głównego
require_writepage() , ryzykujemy również naruszeniem csum w przypadku tych pętli
zgłoszenia. Zapisy strefowe są ograniczone do max_zone_append_size i są
nie są wyrównane z folio, więc przesłanie może obejmować dwa folio. Pierwszy
wywoła folio przetwarzane w require_write_cache_pages().
require_write_locked_range(), która prześle częściowy zakres
następne folio, podczas gdy reszta tego folio może być nadal brudna. Więc
czyszczenie brudnych przesłanych sektorów nie wymaga
folio_clear_dirty_for_io() i mamy ten sam problem. Od
require_write_cache_pages() pomija te folia przesłane wsadowo (są to
już zaznaczone do odpisu z przesłania w poprzednim folio), my
musi dodać dodatkową ochronę przed zapisem w lock_delalloc_folios().

3. W przypadku zakresów inline będzie to nieznacznie wiązać się z ryzykiem utraty zapisów
po/w trakcie kopiowania zakresu wbudowanego, ale przed usunięciem brudu
folio.

4. W przypadku folio obejmujących EOF, mmap może manipulować wcześniejszymi zerowanymi bajtami
EOF i spowodować ich utrwalenie tam, gdzie przyszłe błędy wystąpią nieprawidłowo
zobacz je zamiast zer.

5. Wreszcie, w przypadku skompresowanych zakresów, ryzykujemy modyfikację folio w trakcie
pracuj nad ich kompresją, co spowoduje uszkodzenie skompresowanych danych.
W szczególności w run_delalloc_compressed() ustawiamy w kolejce pracę do wykonania
compress_file_range() w fragmentach BTRFS_COMPRESSION_CHUNK_SIZE (512 KB), które
wywoła btrfs_folio_clamp_clear_dirty() w zakresie. W przypadku braku podstrony,
to zawsze bezpiecznie wyczyści całe folio. W przypadku podstrony ryzykujemy a
również tutaj częściowo jasne. W szczególności wyobraź sobie, że folio 2M jest podzielone
na fragmenty pracy o wielkości 512 tys., co może rozpocząć kompresję jednego fragmentu
zanim wszystkie fragmenty pracownicy compress_file_range() dotrą daleko
wystarczy, aby zakończyć czyszczenie wszystkich brudnych map bitowych folio i pobrać
do folio_clear_dirty_for_io(). Duże folio na krawędziach zgłoszenia
zakresy są podobnie narażone na ryzyko jedynie częściowego oczyszczenia.
Ta szczególna luka została wprowadzona przez drugą łatkę z tej samej serii:
zatwierdzenie a4ef54dbb576 („btrfs: make require_range_clear_dirty_for_io() do obsługi rozmiaru sektora < przypadki rozmiaru strony”)

Nie możemy po prostu przywrócić wywołania folio_clear
---obcięty---

In the Linux kernel, the following vulnerability has been resolved:

btrfs: write-protect folios during data writeback

commit 095be159f3eb ("btrfs: unify folio dirty flag clearing") replaced
the folio_clear_dirty_for_io() call in extent_write_cache_pages() with a
plain folio_test_dirty() check. Besides clearing the dirty flag,
folio_clear_dirty_for_io() also calls folio_mkclean(), which write-protects
the shared mmap PTEs mapping the folio. Note that we still do call
folio_clear_dirty_for_io() later in submit_one_sector() when we clear
dirty on the last sector of the folio (the only sector for non-subpage
cases). But we lost this early call in extent_write_cache_pages().

Without the extra write-protection, a process with the file mmap-ed can
modify a sector while it is being used by writeback in a way that
expects a stable folio (checksumming, compressing, copying, etc...)
without faulting, which manifests as a handful of concrete bugs.

1. For large folios or subpage sectorsize, it is possible to submit a bio
which does not cover the whole folio. When this happens, we will have a
bio in flight for a folio that we have *not* called
folio_clear_dirty_for_io() on. If a task with an existing mmap-ed PTE
writes (without faulting..) in this window, it can result in
corruptions. If the write arrives while the checksumming or writing itself
is underway, this can result in an invalid checksum and later corruption
reports on read. If the write arrives after checksumming/writing is done
but before the last sector dirty is cleared, then the write is present
in page cache but doesn't affect the dirty tracking and will be lost
when the folio is fully finished being submitted and the dirty bit
is cleared. This results in losing the write even if fsync() is called.

2. For zoned submissions which are done in batch separate from the main
extent_writepage() loop, we also risk csum violations for those
submissions. Zoned writes are clamped to max_zone_append_size and are
not aligned with folios, so a submission can span two folios. The first
folio being processed in extent_write_cache_pages() will call
extent_write_locked_range() which will submit the partial range of the
next folio, while the rest of that folio could still be dirty. So
clearing dirty on the submitted sectors doesn't call
folio_clear_dirty_for_io() and we have the same issue. Since
extent_write_cache_pages() skips these batch submitted folios (they are
already marked for writeback from submission by the preceding folio), we
must add the extra write protection in lock_delalloc_folios().

3. For inline extents this will subtly risk losing writes that happen
after/while we copy the inline extent but before we clear dirty on
the folio.

4. For folios spanning EOF, mmap could tamper with the zeroed bytes past
EOF and cause them to be persisted where future faults would improperly
see them instead of zeros.

5. Finally, for compressed extents, we risk modifying the folios while we
work on compressing them which will result in corrupted compressed data.
Specifically, in run_delalloc_compressed() we queue up work to do
compress_file_range() in BTRFS_COMPRESSION_CHUNK_SIZE (512K) chunks which
will call btrfs_folio_clamp_clear_dirty() on the range. For non-subpage,
this will always clear the whole folio, safely. For subpage, we risk a
partial clear here as well. In particular, imagine a 2M folio broken up
into 512K chunks of work which might start compression work on one chunk
before all the chunks compress_file_range() workers have gotten far
enough to finish clearing all the dirty bitmaps of the folio and getting
to folio_clear_dirty_for_io(). Large folios on the edges of submission
ranges are similarly at risk to be only partly cleared.
This particular gap was introduced by a second patch in the same series:
commit a4ef54dbb576 ("btrfs: make extent_range_clear_dirty_for_io() to handle sector size < page size cases")

We cannot simply restore the call to folio_clear
---truncated---

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