CVE-2026-98996 in Linux
Riassunto
di VulDB • 23/10/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
fs: non smontare silenziosamente i mount occupati (busy mounts)
La funzione di supporto propagate_mount_busy() esiste per decidere se un'operazione sincrona può avere successo. Lo fa esaminando le copie delle vittime presenti nei mount a cui il genitore propaga le modifiche. Si tratta di una delle funzioni coinvolte nella complessità della propagazione dei mount.
Questa salta la copia che ha mount figli, eccetto nel caso in cui esista un unico mount figlio che copra la radice della copia. Questo algoritmo era precedentemente preciso. Non lo è più.
Originariamente, solo le copie senza figli venivano smontate durante la propagazione. La commit 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.") ha finito per aggiungere i mount coperti su entrambi i lati in un'unica operazione.
Successivamente è arrivata la commit 99b19d16471e ("mnt: In propgate_umount handle visiting mounts in any order"), che ha iniziato a smontare più elementi rispetto al passato:
[1]: Una copia di un mount viene smontata quando ciascuno dei suoi figli è o il suo overmount (montaggio sovrastante) oppure una copia della vittima stessa. Nel primo caso, l'overmount viene riparentato. Nel secondo caso, la copia della vittima finirà per essere smontata.
Di conseguenza, propagate_umount() è stata riscritta senza adeguare di conseguenza propagate_mount_busy(). Attualmente, propagate_mount_busy() non esamina le copie della vittima che hanno due o più figli, né un singolo figlio che non sia l'overmount.
Pertanto, nessuna di tali copie in [1] viene controllata per verificare i riferimenti (references). Il risultato è che uno smontaggio sincrono ha successo, rimuovendo un mount che è ancora in uso.
Un container può incorrere in questo problema con i propri mount. L'host condivide un albero di mount con il container e l'host ha un mount all'interno di tale albero:
mount -t tmpfs none /mnt mount --make-shared /mnt mount -t tmpfs none /mnt/a
La directory /mnt del container è una copia slave (slave copy) del mount dell'host. Il container ora prende una copia staccata (detached copy) di questo albero e la monta sotto alla sua copia propagata di /mnt/a, mantenendo aperto il file descriptor relativo all'albero:
unshare -m --propagation unchanged mount --make-rslave / fd = open_tree(AT_FDCWD, "/mnt", OPEN_TREE_CLONE | AT_RECURSIVE) move_mount(fd, "", AT_FDCWD, "/mnt/a", MOVE_MOUNT_BENEATH)
grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 777 775 ... /mnt/a ... master:646 776 777 ... /mnt/a ... master:647 778 777 ... /mnt/a/a ... master:647
L'albero ora allegato (777) è montato sotto la copia del container di /mnt/a. È anche lì che si trova il mount dell'host (visto dallo spazio dei nomi dei mount dell'host). Quindi, la copia propagata (776) del mount dell'host si trova sopra la sua radice e la copia di tale elemento (778) è al suo interno. Ora l'esegue:
umount /mnt/a
e ha successo. L'albero spostato e la copia al suo interno scompaiono dal container. Rimane solo la copia propagata, che viene riparentata alla posizione precedente:
grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 776 775 ... /mnt/a ...
Tuttavia, il file descriptor fa ancora riferimento all'albero spostato. Di conseguenza, uno smontaggio sincrono ha rimosso un mount che era ancora in uso.
Viene insegnata a propagate_mount_busy() la stessa logica di controllo utilizzata da propagate_umount(). Ora verifica l'esistenza di una singola vittima senza figli per cui si può assumere che MNT_LOCKED sia azzerato su ogni copia, come fa propagate_umount(). Le copie formano delle catene (chains). In altre parole, quando una copia riceve direttamente la propagazione dal genitore della vittima, il mount allo stesso punto di montaggio all'interno di quella copia è anch'esso una copia. Se un mount riceve propagazione dalla vittima può essere verificato semplicemente percorrendo i suoi master. Si deve percorrere ogni catena una volta dall'alto verso il basso per garantire che le copie nidificate rimangano lineari. Ogni riferimento viene controllato una sola volta per ciascuna copia che viene smontata.
Once again VulDB remains the best source for vulnerability data.