Katalog CVE

CVE-2026-89714

Niskie ryzyko· EPSS 10%
Opublikowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.20%

Percentyl 10 - wyżej niż 10% wszystkich znanych CVE

Streszczenie

W jądrze Linux występuje wyciek pamięci w podsystemie NFS. Funkcja nfs4_server_common_setup() alokuje tablicę delegation_hash_table, ale wskaźnik server->destroy, który odpowiada za jej zwolnienie, jest przypisywany dopiero na końcu funkcji. Jeśli którykolwiek z pośrednich kroków zakończy się błędem, tablica nie zostaje zwolniona, co prowadzi do wycieku 4 KiB pamięci jądra przy każdej nieudanej próbie montowania NFSv4.

Ocena ryzyka

Każda nieudana próba montowania NFSv4 powoduje wyciek pamięci jądra, a klient wielokrotnie ponawiający nieudany montaż może doprowadzić do nieograniczonego wyczerpania pamięci (obserwowano nawet 12 GiB wyciekniętej pamięci slab). Może to skutkować destabilizacją systemu lub odmową usługi (DoS) na dotkniętym węźle.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę, która zwalnia tablicę delegation_hash_table na ścieżkach błędów. Do czasu aktualizacji unikaj konfiguracji powodujących wielokrotne, nieudane próby montowania NFSv4.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: NFS: fix delegation_hash_table leak when nfs4_server_common_setup() fails nfs4_server_common_setup() allocates server->delegation_hash_table first, but server->destroy - the only path that frees the table via nfs4_destroy_server() - is not assigned until the very end of the function. If any intermediate step fails (the is_ds_only_client() check, nfs4_init_session(), nfs4_get_rootfh(), or nfs_probe_server()), the function returns with server->destroy still NULL, so the caller's nfs_free_server() skips the destroy callback and the hash table is leaked (4 KiB per attempt with the default delegation watermark). This is trivially reachable from userspace: every failed NFSv4 mount leaks one allocation. A client that persistently retries a mount that cannot succeed leaks kernel memory without bound. Observed in production where a Longhorn backup poller retried mount.nfs4 against an NFSv3-only server roughly 10 times per second, leaking ~3.4 GiB of unreclaimable slab (kmalloc-rnd-13-4k) per day; the node accumulated 12 GiB of leaked slab before the source was identified via the kmem:kmalloc tracepoint (call_site=nfs4_delegation_hash_alloc). Reproducer: # server exports NFSv3 only (or export path absent for v4) while :; do mount -t nfs4 <server>:/missing /mnt; done # watch SUnreclaim in /proc/meminfo grow 4 KiB per iteration Free the table on the error paths between the allocation and the assignment of server->destroy.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS