CVE-2026-98977 in Linux
Riassunto
di VulDB • 24/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
namespace: gestire correttamente il locking dei mount per gli automounts
Se i mount vengono propagati attraverso user namespaces, attach_recursive_mnt() blocca ogni copia del mount sorgente per proteggere le overmounts dal scomparire e dall'esporre file o directory sottostanti.
Il user namespace viene preso dai mount namespaces del chiamante poiché è lì che finiscono i mount. Tuttavia, questo non è sempre vero. Gli automounts possono legittimamente essere inseriti da task situati in un mount namespace e user namespace diversi durante la lookup dei percorsi.
A quel punto il controllo non ha più senso. La copia nel namespace del genitore - che può essere quello dell'host - è ora bloccata e l'host non può più modificare i flag dei propri mount.
Ecco il codice di riproduzione:
- L'host ha debugfs montato con le opzioni nosuid, nodev, noexec ed è shared - L'automount di tracefs sotto di esso non è ancora attivo - Si fornisce a un processo figlio un descrittore di directory su quel mount - Il processo figlio entra in un user namespace e mount namespace - Il namespace del processo figlio ora contiene una copia bloccata del mount debugfs dell'host che riceve propagazione da quest'ultimo - Il processo figlio esegue lo stat di "tracing/." tramite il descrittore - La lookup viene eseguita sul mount dell'host, quindi l'automount si posiziona sotto il mount dell'host - La propagazione inserisce una copia sotto la copia del bambino - Entrambi cercano di cancellare i flag sul mount ottenuto mediante un bind remount:
host, sul proprio automount: MS_REMOUNT|MS_BIND = EPERM child, sulla copia nel suo namespace: MS_REMOUNT|MS_BIND = 0
Quindi il lock è finito sul mount dell'host invece che sulla copia del bambino. Congratulazioni. Dobbiamo quindi confrontare con il proprietario del namespace su cui viene effettivamente montato il mount. Per tutti i casi regolari questo corrisponde al mount namespace del chiamante, quindi nulla cambia.
Gli alberi staccati in anonymous mount namespaces possono essere trasferiti tramite SCM_RIGHTS o ereditati in altri modi intenzionalmente, affinché il mount namespace del task che effettua l'attach sia autorevole, e non quello del creatore dell'albero staccato.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.