CVE-2026-98989

W jądrze Linuksa usunięto następującą lukę:

przestrzeń nazw: sprawdź rekurencyjne montowanie wiązania dla pętli przestrzeni nazw montowania

do_loopback() odmawia powiązania pliku montującego z przestrzeni nazw montowania, która
jest tak stary jak obiekt wywołujący lub starszy, ponieważ posiada przestrzeń nazw montowania
zamontowanie własnego pliku lub pliku przodka spowodowałoby cykl. Ale
sprawdza tylko ząb, od którego zaczyna się mocowanie wiązania. Z MS_REC
wszystko poniżej jest kopiowane, a funkcja do_loopback() przechodzi
CL_COPY_MNT_NS_FILE, więc zamontuj pliki przestrzeni nazw poniżej źródła
skopiowane.

To jest w porządku dla źródła w przestrzeni nazw montowania wywołującego. Każdy
zamontuj tam plik przestrzeni nazw, który przeszedł tę samą kontrolę, kiedy to było
montowany na wiązanie. Nie jest w porządku, jeśli źródło znajduje się w innej przestrzeni nazw montowania.
may_copy_tree() akceptuje montowanie wiązania dowolnego pliku nsfs lub pidfs bez względu na to
w jakiej przestrzeni nazw montowania się znajduje, aby /proc/<pid>/ns/<ns> i pidfds
można zamontować na wiązanie. Jeśli utworzymy stos montowanych przestrzeni nazw typu bind-mount
deskryptory plików, jądro skopiuje je niezależnie od ich
związek przodków z daną przestrzenią nazw montowania:

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

Mocowanie 152 jest mocowaniem pliku przestrzeni nazw montowania przestrzeni nazw montowania
4026532293 wewnątrz przestrzeni nazw montowania 4026532293. Ta przestrzeń nazw i każda
uchwytu w nim wyciekły... Wystarczy przeprowadzić proces w starszym mocowaniu
przestrzeń nazw, która układa plik i powtarzając go, wycieka bez ograniczeń:

po kontroli: Shmem: 380 kB
dziecko: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok
po cyklu: Shmem: 65916 kB

do_move_mount() uruchamia funkcję check_for_nsfs_mounts() na odłączonym drzewie dla
dokładnie z tego powodu. Zrób to samo z kopią przed jej przeszczepieniem.