CVE-2026-98991: fallo de gravedad alta en Linux
namespace: queue a mount only once for mount notifications
Publicada el · Actualizada el
21Vexday Risk Score
Sin señal de explotación. Ningún artefacto público de explotación conocido hasta ahora.
ssvc Trackcvss 7.8epss 0.2%
probabilidad de explotación
0.2%top 95% de las CVE
explotación observada
noninguna fuente lo reporta
In the Linux kernel, the following vulnerability has been resolved:
namespace: queue a mount only once for mount notifications
mnt_notify_add() puts a mount on notify_list. It doesn't check whether
the mount is on the list already. That's fine as long as every mount is
queued at most once per namespace_sem hold. It isn't.
propagate_umount() moves a surviving overmount off a stack of mounts
that are going away and queues it as moved. shrink_submounts() and
mark_mounts_for_expiry() call umount_tree() for several mounts under a
single namespace_sem hold. So the second umount_tree() can take down
exactly the mount the first one reparented, reparent it once more and so
end up queueing it a second time.
The second list_add_tail() cuts the mounts queued in between out of the
list while the head still points at the last of them. notify_mnt_list()
then only visits that one mount and the others are freed after the grace
period with notify_list still pointing at them. Every later mount
operation on the host walks freed memory:
BUG: KASAN: slab-use-after-free in __list_add_valid_or_report
Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162
__list_add_valid_or_report+0x15c/0x1a0
mnt_add_to_ns+0x322/0x890
attach_recursive_mnt.isra.0+0xf2a/0x1a00
path_mount+0x139c/0x1d40
This needs a mount with MNT_SHRINKABLE to bind from. That's what
finish_automount() creates (submounts of NFS, AFS and CIFS and the
tracefs mount below debugfs). Bind mounts inherit the flag. A mount
namespace with a FAN_MARK_MNTNS mark does the rest and root in a user
namespace can have both.
Initialize to_notify in alloc_vfsmnt() and leave a mount alone that is
queued already. mnt_notify() looks at the state the mount has when the
list is drained so a single entry per mount is enough. The move event
for a mount that is unmounted under the same hold is lost. That's fine.
The detach is what matters.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Productos afectados
Linux · LinuxCVEs relacionadas — Linux
En el mismo producto, de las más peligrosas a las menos.
CVE-2026-31431HIGHcrypto: algif_aead - Revert to operating out-of-placeEPSS 98.1%KEVCVE-2024-53197HIGHALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devicesEPSS 4.1%KEVCVE-2024-53104HIGHmedia: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_formatEPSS 3.4%KEVCVE-2025-39682CRITICALtls: fix handling of zero-length records on the rx_listEPSS 3.3%KEVCVE-2024-36971HIGHnet: fix __dst_negative_advice() raceEPSS 2.7%KEVCVE-2025-39964HIGHcrypto: af_alg - Disallow concurrent writes in af_alg_sendmsgEPSS 1.6%KEV