CVE-2026-74591
KrytyczneCVSS 9.8Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 37 - wyżej niż 37% wszystkich znanych CVE
Streszczenie
W jądrze Linux wykryto podatność w funkcji __filemap_add_folio() w module mm/filemap. Podczas ponawiania próby wstawienia strony (folio) do xarray, indeks nie był przywracany do pierwotnej wartości, co mogło prowadzić do umieszczenia folio pod błędnym (zaokrąglonym w dół) indeksem. Problem objawiał się rzadkimi błędami SIGILL i SIGSEGV w produkcji, gdyż kod wykonywalny znajdował się w niewłaściwej stronie pamięci.
Ocena ryzyka
Podatność może powodować awarie systemu (SIGILL, SIGSEGV) oraz uszkodzenie integralności danych w pamięci, co w środowisku produkcyjnym może prowadzić do nieprzewidywalnych zachowań aplikacji i potencjalnej utraty danych. W skrajnych przypadkach może być wykorzystana do eskalacji uprawnień lub destabilizacji systemu.
Rekomendacja
Zaleca się natychmiastowe zastosowanie oficjalnej łatki z jądra Linux, która przywraca indeks przed ponowieniem pętli w __filemap_add_folio(). Należy zaktualizować system do wersji jądra zawierającej poprawkę oraz monitorować komunikaty o błędach związanych z folio_contains().
Inne podatności w Linux kernel
Zobacz wszystkie- CVE-2026-98374Nieznane
W jądrze Linux występuje podatność use-after-free w tcp_send_synack() dotycząca retransmit_skb_hint. Gdy tcp_send_synack() zastępuje sklonowany SYN skb na początku kolejki retransmisji kopią, zwalnia oryginał, ale tp->retransmit_skb_hint nadal wskazuje na zwolniony obiekt, co może być wykorzystane przez nieuprzywilejowanego klienta TFO do wywołania use-after-free.
- CVE-2026-98373Nieznane
W jądrze Linux występuje błąd w move_hugetlb_page_tables(), gdzie adres docelowy jest przesuwany zbyt daleko, gdy offsety w tablicach stron źródłowej i docelowej różnią się. Może to prowadzić do paniki jądra na x86-64.
- CVE-2026-98048Nieznane
W jądrze Linux w podsystemie BPF funkcja mark_fastcall_pattern_for_call() musi zapewnić, że dopasowana sekwencja instrukcji "spill; call; fill" nie jest przerwana przez skok. W przeciwnym razie przepisanie zastosowane przez bpf_remove_fastcall_spills_fills() jest niepoprawne. Poprawka rejestruje instrukcje będące celami skoków w insn_aux_data[*].jump_target i używa tej flagi do zatrzymania rozwijania wzorca.
- CVE-2026-98047Nieznane
W jądrze Linux w podsystemie BPF funkcja in_rbtree_lock_required_cb() sprawdza tylko najgłębszą ramkę weryfikatora, przez co ograniczenia callbacku rbtree znikają w zagnieżdżonej ramce wywołania statycznego podprogramu. Podprogram może odblokować drzewo, usunąć i zwolnić porównywany węzeł, a następnie ponownie zablokować, co prowadzi do wstawienia zwolnionej pamięci do drzewa.
- CVE-2026-98045Nieznane
W jądrze Linux podatność w weryfikatorze BPF dotyczy helperów stosu, które mogą blokować na odczytach systemu plików (np. przy rozwiązywaniu build ID), ale nie były oznaczone jako uśpialne. Weryfikator mógł zezwolić na ich wywołanie z regionów nieuśpialnych, takich jak sekcje RCU czy z wyłączonym wywłaszczaniem.
- CVE-2026-98044Nieznane
W jądrze Linux weryfikator BPF błędnie obsługiwał przestarzałe instrukcje ładowania pakietów (BPF_LD_ABS/BPF_LD_IND) wywoływane z callbacków, co prowadziło do błędu weryfikatora i ostrzeżenia oraz błędu -EFAULT przy BPF_PROG_LOAD. Uprawniony ładowacz programów mógł wywołać ten problem.
- CVE-2026-98043Nieznane
W jądrze Linux weryfikator BPF błędnie wnioskował, że wskaźnik z nieograniczonym przesunięciem jest nie-NULL, opierając się tylko na typie. W wyniku tego program BPF mógł przejść weryfikację, a w czasie działania nastąpiło wyłuskanie wskaźnika NULL.
- CVE-2026-98042Nieznane
W jądrze Linux weryfikator BPF mógł przywrócić identyfikator skalara usunięty przez collect_linked_regs(), ponieważ kopie porównywanych rejestrów były wykonywane przed zebraniem powiązanych rejestrów. Mogło to prowadzić do niespójności zakresów i propagacji precyzji.
- CVE-2026-98041Wysokie
W jądrze Linux weryfikator BPF błędnie przewidywał wynik porównania wskaźnika z zerem w instrukcjach JMP32, nie odróżniając porównań BPF_JMP od BPF_JMP32. Prowadziło to do nieprawidłowego wnioskowania o zawsze wykonanym skoku.
- CVE-2026-98040Nieznane
W jądrze Linux weryfikator BPF nie oznaczał rejestru zerowego jako precyzyjnego przy sprawdzaniu NULL w formie porównania rejestrów. W rezultacie jedna ze ścieżek była przycinana, a program mógł wyłuskać wskaźnik o wartości zero w czasie działania.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: mm/filemap: __filemap_add_folio() restore index before retrying In __filemap_add_folio()'s split-a-conflict loop, xas_set_order() is applied repeatedly: each application modifies xas.xa_index, rounding it down according to the split_order attempted at that stage: and if all goes as intended, it eventually (or immediately) converges on an xas_try_split() to the required folio_order, with xas.xa_index now the same as index: then xas_store() puts the new folio into the xarray there. But if a new node was needed, and GFP_NOWAIT allocation did not get one, the lock is dropped, xas_nomem() used to allocate, and sequence retried. If (that part of) the xarray is unchanged when the lock is reacquired, no problem. But what if the conflict was meanwhile resolved by another thread (perhaps even doing the same thing, inserting a folio at that same index)? Isn't there a danger of now putting our folio into the xarray at an intermediate rounded-down index? With !folio_contains() bug to follow, when CONFIG_DEBUG_VM=y is checking for that. Fix this with an xas_set_order() to restore the original xas.xa_index at the bottom of the loop, so the retry does a full re-evaluation after reacquiring the lock, and cannot reach xas_store() with the wrong index. Production was suffering from rare SIGILLs and SIGSEGVs, executable text found a page away from where it belonged, !folio_contains() bug hit when debug enabled: symptoms not seen since this patch went in.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

