Katalog CVE

CVE-2026-98989

Nieznane
Opublikowano: Przetłumaczono: NVD NIST

Streszczenie

W jądrze Linux naprawiono podatność w obsłudze przestrzeni nazw mountów, gdzie rekurencyjne bind-mountowanie plików przestrzeni nazw (nsfs) mogło prowadzić do cyklicznych zależności i wycieku pamięci. Funkcja do_loopback() sprawdzała tylko początkowy dentry, a przy MS_REC kopiowała pliki przestrzeni nazw poniżej źródła bez weryfikacji, czy nie tworzą one pętli. Umożliwiało to procesowi w starszej przestrzeni nazw wielokrotne wyciekanie pamięci poprzez stackowanie bind-mountów.

Ocena ryzyka

Lokalny atakujący z odpowiednimi uprawnieniami może wywołać nieograniczony wyciek pamięci jądra (shmem), prowadząc do wyczerpania zasobów i odmowy usługi (DoS) dla całego systemu.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę. Do czasu aktualizacji ogranicz możliwość wykonywania operacji mount w niezaufanych przestrzeniach nazw (np. przez polityki seccomp/AppArmor).

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: namespace: check a recursive bind mount for mount namespace loops do_loopback() refuses to bind mount the file of a mount namespace that is as old as the caller's or older because a mount namespace that holds a mount of its own file, or of an ancestor's, would cause a cycle. But it only checks the dentry the bind mount starts from. With MS_REC everything below it is copied and do_loopback() passes CL_COPY_MNT_NS_FILE so mount namespace files below the source are copied. That's fine for a source in the caller's own mount namespace. Every mount namespace file in there passed the same check when it was bind-mounted. It isn't fine for a source in another mount namespace. may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter what mount namespace it lives in so that /proc/<pid>/ns/<ns> and pidfds can be bind mounted. If we create a bind-mount stack of mount namespaces file descriptors the kernel will copy them irrespective of their ancestoral relationship to the mount namespace in question: 151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw 152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw Mount 152 is a mount of the mount namespace file of mount namespace 4026532293 inside mount namespace 4026532293. That namespace and every mount in it are leaked... All it takes is a process in an older mount namespace that stacks the file and repeating it leaks without limit: after control: Shmem: 380 kB child: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok after cycle: Shmem: 65916 kB do_move_mount() runs check_for_nsfs_mounts() over a detached tree for exactly that reason. Do the same for the copy before it is grafted.

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