CVE-2026-98151
NieznaneStreszczenie
W jądrze Linux występuje błąd w weryfikatorze BPF dotyczący arytmetyki na wskaźnikach w ścieżce spekulatywnej. Podczas przetwarzania operacji dodawania do wskaźnika (r0 += r1) stan rejestru jest migawkowany w momencie, gdy pole var_off i zakres 32-bitowy są niespójne, co prowadzi do naruszenia niezmienników rejestru i ostrzeżenia weryfikatora. Problem dotyczy programów nieuprzywilejowanych i został naprawiony poprzez przeniesienie wywołania __mark_reg32_unbounded() za funkcję sanitize_ptr_alu().
Ocena ryzyka
Niespójny stan rejestru w weryfikatorze BPF może prowadzić do błędnej weryfikacji programów eBPF, potencjalnie umożliwiając obejście mechanizmów bezpieczeństwa lub wywołanie awarii jądra (panic). W środowiskach z nieuprzywilejowanymi programami BPF może to zostać wykorzystane do eskalacji uprawnień lub przeprowadzenia ataku odmowy usługi.
Rekomendacja
Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla CVE-2026-98151. Jeśli aktualizacja nie jest możliwa, rozważ ograniczenie możliwości ładowania nieuprzywilejowanych programów BPF poprzez ustawienie kernel.unprivileged_bpf_disabled=1.
Inne podatności w Linux kernel
Zobacz wszystkie- CVE-2026-98162Nieznane
W jądrze Linux w funkcji smb2_tree_connect() serwera SMB (ksmbd) występuje wyciek połączenia drzewa (tree connection). Gdy funkcja ksmbd_iov_pin_rsp() zakończy się niepowodzeniem, nowo utworzone połączenie drzewa nie jest rozłączane, co prowadzi do wycieku zasobów.
- CVE-2026-98161Nieznane
W jądrze Linux w podsystemie nvdimm (pmem) funkcja pmem_submit_bio() rejestruje błąd REQ_PREFLUSH, ale kontynuuje kopiowanie danych bio i może nadpisać błąd udanym flushowaniem REQ_FUA. Pozwala to na wykonanie zapisów danych po nieudanym preflushu i zakończenie bio sukcesem mimo naruszonej bariery kolejności.
- CVE-2026-98160Nieznane
W jądrze Linux w sterowniku staging rtl8723bs funkcja rtw_sdio_if1_init() zwalnia bufor padapter->HalData za pomocą kfree(), mimo że został on przydzielony przez vzalloc(). Użycie kfree() do zwolnienia bufora opartego na vmalloc może prowadzić do uszkodzenia pamięci.
- CVE-2026-100079Nieznane
W jądrze Linux w podsystemie USB Type-C (ucsi) funkcja ucsi_register() tworzy wpisy debugfs dla instancji, ale ucsi_unregister() nie usuwa ich aż do wywołania ucsi_destroy(). Sterowniki takie jak ucsi_glink, które wyrejestrowują i rejestrują tę samą instancję UCSI przy restarcie remoteproc, próbują utworzyć już istniejący katalog debugfs.
- CVE-2026-100078Nieznane
W jądrze Linux w sterowniku wifi iwlwifi (mei) funkcja iwl_mei_write_cyclic_buf() otrzymuje nieprawidłowy pierwszy argument — zamiast cldev przekazywany jest wskaźnik q_head. Błąd został naprawiony.
- CVE-2026-100077Nieznane
W jądrze Linux w sterowniku drm/msm podczas odzyskiwania GPU nie jest bezpieczne wycofywanie zawieszonego zgłoszenia (submit) przed zakończeniem odzyskiwania GPU. Wycofanie zgłoszenia powoduje zwolnienie buforów BO, do których GPU może wciąż aktywnie uzyskiwać dostęp, co prowadzi do błędów strony (pagefaults).
- CVE-2026-100074Nieznane
W jądrze Linux naprawiono błąd w podsystemie BPF, w którym pole BPF_REFCOUNT nie było oznaczane jako unikalne, mimo że powinno być. Poprawka usuwa to przeoczenie.
- CVE-2026-100073Nieznane
W jądrze Linux naprawiono błąd w systemie plików ext4 dotyczący przepełnienia transakcji podczas zapisu zwrotnego. Poprzednia poprawka zbyt agresywnie zmniejszała liczbę rezerwowanych kredytów transakcyjnych, co w niektórych przypadkach prowadziło do niewystarczającej rezerwy. Poprawka używa funkcji ext4_meta_trans_blocks() do prawidłowego oszacowania górnej granicy.
- CVE-2026-100072Nieznane
W jądrze Linux naprawiono problem w podsystemie ACPI, gdzie użycie acpi_get_first_physical_node() w acpi_platform_fill_resource() i acpi_create_platform_device() było niebezpieczne, ponieważ zwrócone urządzenie mogło zostać zwolnione w dowolnym momencie. Poprawka zastępuje tę funkcję funkcją acpi_bus_get_primary_device() i dostosowuje kod, aby wywoływać ją tylko raz.
- CVE-2026-100071Nieznane
W jądrze Linux naprawiono wyciek pamięci w module HSR (High-availability Seamless Redundancy). Gdy funkcja hsr_dev_finalize() zawiedzie po zarejestrowaniu procedury obsługi RX, dynamiczne węzły nauczone w tym oknie nie są zwalniane. Poprawka zwalnia obie bazy danych dynamicznych w ścieżce obsługi błędów.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic Take the following unprivileged program as an example: r0 = bpf_map_lookup_elem(...) /* PTR_TO_MAP_VALUE, offset 0 */ ... 14: r0 += r1 /* r1 is a bounded scalar */ 15: r9 = r0 Loading it triggers a verifier warning from reg_bounds_sanity_check(): verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out of sync with range bounds r64={.base=0x0, .size=0x0} r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0) What happens: 1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new offset is computed into dst_reg's var_off and 32/64-bit ranges. 2. Because pointer registers do not track 32-bit subregister bounds, __mark_reg32_unbounded() first sets r32 to the full range; r32 is re-derived from the offset at the end of the function by reg_bounds_sync(). 3. On the unprivileged path, sanitize_ptr_alu() is called and, via sanitize_speculative_path() -> push_stack(), snapshots the current register state and schedules the next instruction (insn 15) to be verified directly as a speculative path. 4. That snapshot is taken between step 2 and the final reg_bounds_sync(): at this point dst_reg's var_off still holds the (const) original offset while r32 has just been blanked to the full range, i.e. the two are out of sync. When the speculative path later verifies insn 15 (r9 = r0), the inconsistent state reaches reg_bounds_sanity_check() and trips the warning. var_off and the 32-bit range must always be consistent. There are two ways to keep the snapshot consistent: 1. sync var_off and r32 before the snapshot so they match, or 2. leave r32 at its original (already consistent) value and blank it only after the snapshot. The whole point of sanitize_ptr_alu() is to insert a harmless masking sequence that keeps the access in bounds under speculation, so the state it snapshots should faithfully represent that. Take approach 2: move __mark_reg32_unbounded() to after sanitize_ptr_alu(), so the speculative snapshot keeps the pointer's original, consistent r32. The non-speculative path is unchanged: r32 is still blanked before the offset is applied and re-derived by reg_bounds_sync().
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS