CVE-2026-53134
ŚrednieCVSS 5.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 7 — wyżej niż 7% wszystkich znanych CVE
Streszczenie
W jądrze Linux wykryto podatność w module netfilter nft_fib, która powoduje wyciek niezainicjalizowanych danych ze stosu jądra do przestrzeni użytkownika. Problem występuje, gdy dla wyniku OIFNAME rejestr docelowy jest deklarowany z długością IFNAMSIZ, ale w przypadku niepowodzenia wyszukiwania zapisywany jest tylko jeden rejestr, pozostawiając pozostałe trzy z danymi ze stosu. Dodatkowo flaga NFTA_FIB_F_PRESENT była akceptowana dla nieprawidłowych typów wyników, co również prowadziło do wycieku.
Ocena ryzyka
Atakujący może wykorzystać tę podatność do odczytu niezainicjalizowanych danych ze stosu jądra, co może prowadzić do ujawnienia poufnych informacji systemowych lub danych innych procesów. Może to stanowić podstawę do dalszej eskalacji uprawnień lub obejścia mechanizmów bezpieczeństwa.
Rekomendacja
Należy niezwłocznie zaktualizować jądro Linux do wersji zawierającej poprawkę (commit: 9b2c2e0c8c5e). Jeśli aktualizacja nie jest możliwa, należy ograniczyć dostęp do funkcji filtrowania pakietów z użyciem nft_fib oraz monitorować system pod kątem nietypowych zachowań.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via "*dest = 0". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare "*dest = 0" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.