Search Results (10435 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-85329 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-24 7 High
Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Account allows an authorized attacker to elevate privileges locally.
CVE-2026-70134 1 Microsoft 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more 2026-10-24 7 High
Use after free in Windows Event Tracing allows an authorized attacker to elevate privileges locally.
CVE-2026-88178 1 Microsoft 11 365 Apps, Microsoft 365, Microsoft Office Ltsc 2021 and 8 more 2026-10-24 9.8 Critical
Use after free in Microsoft Office PowerPoint allows an unauthorized attacker to execute code over a network.
CVE-2026-69931 1 Microsoft 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more 2026-10-24 7 High
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Storage allows an authorized attacker to elevate privileges locally.
CVE-2026-69986 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-24 7.5 High
Use after free in Remote Desktop Client allows an unauthorized attacker to execute code over a network.
CVE-2026-85914 1 Microsoft 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more 2026-10-24 7 High
Use after free in Windows Embedded Mode Service allows an authorized attacker to elevate privileges locally.
CVE-2026-85934 1 Microsoft 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more 2026-10-24 7 High
Use after free in Windows AppX Deployment Service allows an authorized attacker to elevate privileges locally.
CVE-2026-70038 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-24 8.1 High
Use after free in Windows iSCSI allows an unauthorized attacker to execute code over a network.
CVE-2026-96308 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-24 7.8 High
Use after free in Windows Installer allows an authorized attacker to elevate privileges locally.
CVE-2026-70237 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-24 7 High
Use after free in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.
CVE-2026-96302 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-24 7 High
Use after free in Windows Installer allows an authorized attacker to elevate privileges locally.
CVE-2026-96108 1 Microsoft 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more 2026-10-24 7.8 High
Use after free in Desktop Window Manager allows an authorized attacker to elevate privileges locally.
CVE-2026-96317 1 Microsoft 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more 2026-10-24 7.8 High
Use after free in Windows Kernel allows an authorized attacker to elevate privileges locally.
CVE-2026-69452 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-24 7.1 High
Use after free in Windows Enterprise App Management allows an authorized attacker to elevate privileges over a network.
CVE-2026-69992 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-24 7.5 High
Use after free in Windows Remote Desktop Services allows an unauthorized attacker to execute code over a network.
CVE-2026-98982 1 Linux 2 Linux, Linux Kernel 2026-10-24 7.8 High
In the Linux kernel, the following vulnerability has been resolved: namespace: don't let a pseudo dentry become the root of a mount d_alloc_pseudo() hands out dentries for pipes, sockets and other files that are never anyone's child or parent. They carry DCACHE_NORCU and dentry_free() frees them right away because no lockless path walk can ever reach them. That holds as long as such a dentry isn't the root of a mount. But bind mounting /proc/self/fd/<fd> of such a file does exactly that. Most callers of alloc_file_pseudo() put their files on kernel-internal mounts and may_copy_tree() refuses those. bpf_token_create() doesn't. It places the token file on the bpffs mount the caller handed it and that mount is in the caller's mount namespace so the clone goes through: mount --bind /proc/self/fd/<token> <file> open_tree(tokfd, "", AT_EMPTY_PATH | OPEN_TREE_CLONE) + move_mount() __follow_mount_rcu() then loads ->mnt_root of that mount, reads d_seq and d_flags of the dentry and only then checks mount_lock. The dentry can be gone by then. The final mntput() of an unmounted parent unhooks a child that stayed attached to it under mount_lock alone. When the child's holder does the final put right after that the root is dput() and freed immediately while a walker that found the mount hashed still looks at it. Refuse to clone a mount with a DCACHE_NORCU dentry as its root. Nothing sensible can be done with a bind mount of a bpf token anyway.
CVE-2026-83718 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-24 7 High
Use after free in Windows Installer allows an authorized attacker to elevate privileges locally.
CVE-2026-85906 1 Microsoft 17 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 14 more 2026-10-24 7.8 High
Use after free in Windows Direct Composition allows an authorized attacker to elevate privileges locally.
CVE-2026-98980 1 Linux 2 Linux, Linux Kernel 2026-10-24 8.8 High
In the Linux kernel, the following vulnerability has been resolved: namei: don't reveal overmounted entries in refwalk In rcuwalk the dentry is validated before it is accepted. step_into() step_into() rechecks d_seq and __follow_mount_rcu() rechecks mount_lock. An entry that gets unlinked in between causes the lookup to retry and miss. A refwalk doesn't do this. lookup_fast() takes a reference on the hashed dentry and simply accepts it. So an unlink that happens after the reference was taken isn't seen by refwalk. That's fine for a simple file. We just happened to open it before it was unlinked, no problem. For a mountpoint and specifically a locked mountpoint it very much isn't. The unlink detaches all mounts and then removes the name. Any refwalk that hasn't traversed the mounts yet simply reveals the underlying entry. It's a very narrow window but it can be hit: reads of a covered file in 60 s, 3 walkers, ~15000 unlinks no widening 27 that step + 200 us 3741 See the appended patch for a more reliable reproducer. So check the entry after step_into(). unlink(), rmdir() and rename() mark the dentry with dont_mount() before they detach the mounts and remove the dentry. So a dentry that is marked with DCACHE_CANT_MOUNT and is unhashed by the time its mounts were looked at is a name that was unlinked under the refwalk. DCACHE_CANT_MOUNT is read after the mounts were looked up and it is set before they are detached by detach_mounts(). A refwalk that missed the mounts will see DCACHE_CANT_MOUNT. Plain d_unlinked() is fine. A rename takes the dentry off its hash chain but ___d_drop() leaves d_hash.pprev set. So only __d_drop() and a rename over the dentry unhash it. The only move that flips IS_ROOT splices in a disconnected alias. That doesn't have DCACHE_CANT_MOUNT set. Add the to step_into_slowpath(). ".." and LOOKUP_DOWN may legitimately land on an unhashed directory. A refwalk that crossed onto a mount has path.mnt different from nd->path.mnt. A dentry that a filesystem dropped on its own (d_invalidate(), d_drop()) doesn't have the flag set and is treated as before. // SPDX-License-Identifier: GPL-2.0 /* * unlink_covered: unlink a file that is a mountpoint in a detached copy of * its mount, against walkers that open it through that copy. * * A is a tmpfs with the file f1 (content SECRET_F) and the plain file * MARK_A. A' is an open_tree(OPEN_TREE_CLONE) copy of A with MARK_A bound * on A'/f1, held through an O_PATH fd on its root once the tree fd is * closed. Walkers open f1 through that fd while the driver unlinks A/f1, * where nothing is mounted on it. A walker may read MARK_A or get ENOENT. * A read of SECRET_F is a hit: the name was found after its mount was * gone. The lockless walks use openat2(RESOLVE_CACHED). * * usage: unlink_covered [-t seconds] [-w walkers] */ #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif #include <errno.h> #include <fcntl.h> #include <pthread.h> #include <stdatomic.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/mount.h> #include <sys/stat.h> #include <sys/syscall.h> #include <linux/openat2.h> #ifndef __NR_open_tree #define __NR_open_tree 428 #endif #ifndef __NR_move_mount #define __NR_move_mount 429 #endif #ifndef __NR_openat2 #define __NR_openat2 437 #endif #ifndef OPEN_TREE_CLONE #define OPEN_TREE_CLONE 1 #endif #ifndef OPEN_TREE_CLOEXEC #define OPEN_TREE_CLOEXEC O_CLOEXEC #endif #ifndef MOVE_MOUNT_F_EMPTY_PATH #define MOVE_MOUNT_F_EMPTY_PATH 0x00000004 #endif #define WORK "/tmp/uc" #define ADIR WORK "/A" static int duration = 60, nwalkers = 3; static atomic_int stop, writer_waiting; static pthread_rwlock_t cur_lock = PTHREAD_RWLOCK_INITIALIZER; static int cur_fd = -1; /* the root of A', -1 while there is none */ static atomic_long n_unlink, n_walk, n_mark, n_enoent, n_othe ---truncated---
CVE-2026-98991 1 Linux 2 Linux, Linux Kernel 2026-10-24 7.8 High
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.