CVE-2026-98989 in Linux
Sumário
de VulDB • 23/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
namespace: verificar se há loops de namespace de montagem em um bind mount recursivo
do_loopback() recusa montar o arquivo de um namespace de montagem que seja tão antigo quanto ou mais antigo que o do chamador, pois um namespace de montagem que contenha uma montagem de seu próprio arquivo, ou de um ancestral, causaria um ciclo. No entanto, ele verifica apenas o dentry a partir do qual o bind mount começa. Com MS_REC, tudo abaixo dele é copiado e do_loopback() passa CL_COPY_MNT_NS_FILE para que os arquivos do namespace de montagem abaixo da origem sejam copiados.
Isso está correto se a origem estiver no próprio namespace de montagem do chamador. Cada arquivo de namespace de montagem lá passou pela mesma verificação quando foi bind-mounted. Não é adequado se a origem estiver em outro namespace de montagem. may_copy_tree() aceita um bind mount de qualquer arquivo nsfs ou pidfs, independentemente do namespace de montagem em que ele reside, para que /proc/<pid>/ns/<ns> e pidfds possam ser bind mounted. Se criarmos uma pilha de bind-mounts dos descritores de arquivos dos namespaces de montagem, o kernel os copiará independentemente de sua relação ancestral com o namespace de montagem em questão:
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
A montagem 152 é uma montagem do arquivo de namespace de montagem do namespace de montagem 4026532293 dentro do namespace de montagem 4026532293. Esse namespace e todas as suas montagens são vazados... Basta um processo em um namespace de montagem mais antigo que empilhe o arquivo e repita isso para vazar sem limite:
após controle: Shmem: 380 kB filho: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok após ciclo: Shmem: 65916 kB
do_move_mount() executa check_for_nsfs_mounts() em uma árvore desanexada exatamente por esse motivo. Faça o mesmo para a cópia antes que ela seja enxertada (grafted).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.