Odebrany

CVE-2026-92500

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: użyj fsdata do śledzenia stanu zapisu danych w linii i naprawienia wyścigu

Zamiast sprawdzać aktywny stan i-węzła (ext4_has_inline_data(inode)
i ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) w
obsługi write_end, użyj parametru fsdata przestrzeni adresowej
operacje, aby jawnie przekazać stan, w którym write_begin
przygotował tekst.

Współbieżny wątek (taki jak ext4_page_mkwrite()) może konwertować plik
dane wbudowane w zakresie pomiędzy write_begin i write_end. Jeśli to
się stanie, procedury obsługi write_end poprzednio przegapiłyby wstawkę
write_end path i przejdź do logiki write_end opartej na zakresie.
Jednakże, ponieważ bufory blokowe nigdy nie zostały przydzielone w write_begin,
spowodowało to wyłuskanie wskaźnika NULL lub utratę danych, ponieważ
folio_buffers(folio) miało wartość NULL.

Zdefiniuj EXT4_WRITE_DATA_INLINE (4) jako flagę bitową (bit 2), traktując
fsdata jako flagi bitowe, a nie wzajemnie wykluczające się wyliczenia, które należy zachować
niezależne stany ścieżki zapisu. Komunikuj się z tym stanem poprzez
dane fs:
1) ext4_write_begin() i ext4_da_write_begin() ustawiają
EXT4_WRITE_DATA_INLINE bit w *fsdata poprzez bitowe LUB w przypadku inline
zapis został pomyślnie przygotowany.
2) Przy wejściu ext4_write_begin() czyści bit EXT4_WRITE_DATA_INLINE
aby bezpiecznie obsłużyć ponowne próby VFS (gdzie funkcja Generic_perform_write() omija
inicjalizacja fsdata przy kolejnej próbie skoku).
3) Funkcje obsługi write_end wykonują bitową operację ORAZ, aby sprawdzić, czy
Bit EXT4_WRITE_DATA_INLINE jest ustawiony i wywołuje wbudowany write_end
odpowiednio pomocnika.

Ponadto podczas buforowanego zapisu funkcja ext4_write_inline_data_end()
uzyskuje blokadę xattr po przygotowaniu zapisu. Jeśli współbieżne
błąd strony (ext4_page_mkwrite()) konwertuje dane wbudowane w pewnym zakresie
po procedurach obsługi write_end sprawdź stan, ale wcześniej
ext4_write_inline_data_end() uzyskuje blokadę zapisu xattr,
kolejne sprawdzenie wywoła panikę jądra poprzez
BŁĄD_ON(!ext4_has_inline_data(i-węzeł)).

Aby historia git działała i była czysta, zastąp plik
BUG_ON sprawdź ext4_write_inline_data_end() z wdzięcznym błędem-
obsługa ścieżki ponawiania próby w tym samym zatwierdzeniu. Jeśli dane wbudowane zostaną wyczyszczone
po zablokowaniu xattr bezpiecznie zwalniamy wszystkie zasoby (zwalniając
iloc.bh, odblokowywanie/zakładanie folio, zatrzymywanie aktywnego dziennika
uchwyt transakcji) i zwróć 0 (ponowna próba VFS), aby umożliwić zapis ogólny
path, ponów bezpieczną operację.

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

ext4: use fsdata to track inline data write state and fix race

Instead of checking the live inode state (ext4_has_inline_data(inode)
and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the
write_end handlers, use the fsdata parameter of the address space
operations to explicitly pass down the state in which write_begin
prepared the write.

A concurrent thread (such as ext4_page_mkwrite()) can convert the
inline data to an extent between write_begin and write_end. If this
happens, the write_end handlers would previously miss the inline
write_end path and fall through to extent-based write_end logic.
However, since block buffers were never allocated in write_begin,
this resulted in NULL pointer dereferences or data loss because
folio_buffers(folio) was NULL.

Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating
fsdata as bitwise flags rather than mutually exclusive enums to keep
states of the write path independent. Communicate this state via
fsdata:
1) ext4_write_begin() and ext4_da_write_begin() set the
EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline
write is successfully prepared.
2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit
to safely handle VFS retries (where generic_perform_write() bypasses
the fsdata initialization on its retry jump).
3) The write_end handlers perform a bitwise AND to check if the
EXT4_WRITE_DATA_INLINE bit is set and invoke the inline write_end
helper accordingly.

Furthermore, during a buffered write, ext4_write_inline_data_end()
acquires the xattr lock after preparing the write. If a concurrent
page fault (ext4_page_mkwrite()) converts the inline data to an extent
after the write_end handlers check the state but before
ext4_write_inline_data_end() acquires the xattr write lock, the
subsequent check will trigger a kernel panic via
BUG_ON(!ext4_has_inline_data(inode)).

To keep git history working and bisectability clean, replace the
BUG_ON check in ext4_write_inline_data_end() with a graceful error-
handling retry path in this same commit. If the inline data is cleared
after locking the xattr, we safely release all resources (releasing
iloc.bh, unlocking/putting the folio, stopping the active journal
transaction handle) and return 0 (VFS retry) to let the generic write
path retry the operation safely.

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