CVE-2026-98984 in Linux
Resumen
por VulDB • 2026-10-25
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
dcache: no colocar un punto de montaje en una dentry que está siendo eliminada
rmdir(), unlink() y rename() llaman a dont_mount() sobre el objeto víctima y luego a detach_mounts() con el inode del objeto bloqueado. do_lock_mount() toma el bloqueo del inode del punto de montaje y verifica cant_mount(), por lo que un nuevo montaje no puede aparecer después de detach_mounts().
Sin embargo, attach_recursive_mnt() crea un segundo punto de montaje para la raíz del montaje origen, de modo que los montajes ya ubicados en el destino puedan colocarse encima de él. No se bloquea ningún inode para esta operación y d_set_mounted() solo rechaza una dentry que ha sido desvinculada (unlinked). Entre detach_mounts() y d_delete(), la víctima sigue estando hashada:
rmrace: b pasó por dont_mount() y detach_mounts(), durmiendo T2: move_mount(S, /tmp/plcant/x, BENEATH) = 0 errno 0 () T1: rmdir(/tmp/plcant/d/b) = 0 errno 0 109 107 0:61 /d/b//deleted /tmp/plcant/x rw,relatime - tmpfs tmpfs rw 108 109 0:63 / /tmp/plcant/x rw,relatime - tmpfs T rw
Un bind mount del directorio que se está eliminando se mueve debajo de un montaje existente mientras la operación rmdir() se encuentra entre las dos llamadas. El montaje termina quedando en el directorio eliminado y nada lo desvinculará nunca.
Verificar cant_mount() también dentro de d_set_mounted(). dont_mount() establece la bandera bajo d_lock antes de que se ejecute detach_mounts(), por lo que o bien el punto de montaje se configura primero y detach_mounts() encuentra el montaje, o bien se detecta la bandera y el montaje es rechazado.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.