CVE-2026-90133

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

ntfs: Napraw zapis OOB sterty_głównego indeksu w ntfs_ir_to_ib()

ntfs_ir_to_ib kopiuje wszystkie wpisy z katalogu katalog_główny_indeksowy do świeżo przydzielonego pliku
indeks_bloku_rozmiaru bajtów bez sprawdzania, czy wpisy mieszczą się w
dostępna przestrzeń. Wpisy w katalogu root_index mogą być większe niż użyteczne
miejsce na wpis w bloku indeksowym.

Może to spowodować zapis OOB po zakończeniu alokacji.

Walidator ntfs_index_root_inconsistent() sprawdza, czy wpisy są
spójne w zakresie wartości IR, ale nigdy nie sprawdzają ich krzyżowo
rozmiar_bloku_indeksu. Nie ma sprawdzania granic w ntfs_ir_to_ib() przed
memcpy.

Naprawiam to przy zlewie w ntfs_ir_to_ib() od tego czasu
ntfs_index_root_inconsistent() sprawdza logiczną spójność
indeks_root jako struktura, a katalog główny z dużymi wpisami jest strukturalnie
ważny korzeń. Błąd polega na konflikcie rozmiarów funkcji ntfs_ir_to_ib().
Ponadto walidator jest wywoływany raz na załadowanie i-węzła
ntfs_read_locked_inode(), podczas gdy ntfs_ir_to_ib() jest wywoływana tylko podczas
reparent, sprawdzenie tego nie powoduje narzutu na wspólną ścieżkę.
Co więcej, nawet przyszła ścieżka wywołania, która omija moduł sprawdzania poprawności, nadal by to robiła
być chronionym.

Gdy NULL jest pierwszym parametrem ntfs_error(), flaga błędu woluminu to
nigdy nie jest ustawiana przez to wywołanie, więc nazwa urządzenia nie będzie wyświetlana w błędzie
wiadomość. W każdym razie funkcja wywołująca ntfs_ir_reparent() wypisuje błąd
komunikat zawierający nazwę urządzenia w przypadku zwrotów NULL.
Myślę, że to najlepsze rozwiązanie dostępne bez dodawania
„struct super_block *sb” jako parametr funkcji ntfs_ir_to_ib().

Ten zapis poza granicami sterty jest wyzwalany przez spreparowany obraz systemu plików,
czego w każdym razie nie ma w modelu zagrożenia jądra, naprawienie błędów pamięci by to zrobiło
bądź miły, dbając o bezpieczeństwo.