Export limit exceeded: 16062 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 414025 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (414025 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-98964 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-24 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: nvmet: use the local P2P device on metadata allocation failure nvmet_req_alloc_p2pmem_sgls() assigns req->p2p_dev only after the data and metadata SGL allocations succeed. If the data allocation succeeds but the metadata allocation fails, out_free_sg passes req->p2p_dev to pci_p2pmem_free_sgl() before that assignment has taken place. Pass the local p2p_dev argument instead, so cleanup uses the same PCI device as the successful data allocation. | ||||
| 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-70207 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-24 | 7.5 High |
| Heap-based buffer overflow in Network Policy Server (NPS) allows an authorized attacker to execute code over a network. | ||||
| CVE-2026-73027 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-24 | 7.8 High |
| External control of system or configuration setting in Windows Setup Files Cleanup allows an authorized attacker to elevate privileges locally. | ||||
| 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-99042 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-24 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6 io_connect_bpf_populate() fills connect.port and connect.v6_addr for AF_INET6 only when addr_len >= sizeof(struct sockaddr_in6), i.e. 28 bytes. The IPv6 connect paths accept SIN6_LEN_RFC2133 (24 bytes), which already holds sin6_port and sin6_addr. io_connect() passes addr_len to the socket layer unchanged. At addr_len 24 the filter sees family AF_INET6 with port and address zero, while the kernel connects to the real destination. A filter that denies an IPv6 port or address is bypassed. Denying connect.port == P rejects [::1]:P with -EACCES at addr_len 28 but connects at addr_len 24. Use SIN6_LEN_RFC2133 as the threshold. sin6_scope_id stays zero when absent. The threshold mismatch was found by an AI coding assistant (Claude Code) comparing this hook against the net/ipv6 length checks on my instructions; it also drafted the reproducer and this patch. I verified the bypass and the fix in a VM on 7.3-rc6 and that 7.2 has the same code. | ||||
| CVE-2026-83636 | 1 Microsoft | 17 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 14 more | 2026-10-24 | 6.5 Medium |
| Null pointer dereference in Windows Hyper-V allows an authorized attacker to deny service locally. | ||||
| CVE-2026-83697 | 1 Microsoft | 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more | 2026-10-24 | 4.7 Medium |
| Time-of-check time-of-use (toctou) race condition in Windows Modern Device Management (MDM) allows an authorized attacker to perform tampering locally. | ||||
| 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-83773 | 1 Microsoft | 8 Windows 11 24h2, Windows 11 24h2, Windows 11 25h2 and 5 more | 2026-10-24 | 5.5 Medium |
| Exposure of sensitive system information to an unauthorized control sphere in Windows MIDI Service Module allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-83788 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-24 | 4.6 Medium |
| Buffer over-read in Windows RNDIS allows an unauthorized attacker to disclose information with a physical attack. | ||||
| CVE-2026-83797 | 1 Microsoft | 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more | 2026-10-24 | 8.8 High |
| Out-of-bounds read in Windows Partition Management Driver allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-83863 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-24 | 7.8 High |
| Heap-based buffer overflow in Servicing Stack Updates 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-85908 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-24 | 7.8 High |
| Heap-based buffer overflow in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-98975 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: xfs: stop exchanging reflink flags when exchanging mappings When an exchange covers both files from offset 0 to i_disk_size, xmi_can_exchange_reflink_flags() assumes every mapping moved and hands the reflink flag over to the other file. That assumption is wrong. A file can still own shared blocks past i_disk_size, e.g. after EXCHANGE_RANGE_TO_EOF sets a smaller size without unmapping anything. The flag is cleared anyway, and the next write to such a block happens in place instead of CoW, corrupting the other file that shares it. Commit a23eca88448e ("xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN") fixed one instance of this. Rather than add another special case, stop moving the flags. xfs_exchmaps_ensure_reflink() already sets the flag on both inodes before the exchange, so both just keep it. Nothing sets CLEAR_INO{1,2}_REFLINK anymore. Intents logged by older kernels may still carry them; recovery already masks them off, so they stay in the log format mask and are ignored. XFS_IOC_SWAPEXT has the same problem: it moves the reflink flag from one inode to the other along with the extents. Just removing that is not enough here: the exchange path flags both inodes up front in xfs_exchmaps_ensure_reflink(), but swapext has no such step, so the inode receiving the shared extents would be left without the flag. Set it on both inodes instead, and make sure both have a CoW fork, since an inode with the reflink flag is expected to have one. The flag now stays until FALLOC_FL_UNSHARE_RANGE, xfs_scrub, or a truncate to zero removes it. | ||||
| CVE-2026-99017 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-24 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE errata_probe_ghostwrite() only marks the CPU as vulnerable when it is called at the RISCV_ALTERNATIVES_EARLY_BOOT stage, and the mitigation in ghostwrite_enable_mitigation() only takes effect if the vulnerable state was recorded before the boot alternatives are patched. The early boot stage is only executed when CONFIG_RISCV_ALTERNATIVE_EARLY is enabled, which currently is only selected by ERRATA_THEAD_MAE. In a kernel built with ERRATA_THEAD_GHOSTWRITE=y but ERRATA_THEAD_MAE=n, the early alternatives never run, so ghostwrite_state is never set to VULNERABLE: ghostwrite_enable_mitigation() returns false, xtheadvector remains enabled, and sysfs reports "Not affected" on a vulnerable T-Head C9xx CPU. Select RISCV_ALTERNATIVE_EARLY from ERRATA_THEAD_GHOSTWRITE so that the vulnerability is detected in the early boot stage and the default mitigation is applied. | ||||
| CVE-2026-98899 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: mark the rcu locked areas properly When we bump the uref counter, there's no need to keep the rcu lock because the referred hash table can't disappear. Also, from the same reason in mtype_gc we need the rcu lock and not a spinlock. | ||||
| CVE-2026-98976 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: namespace: keep the lock on a mount that a propagated copy is moved beneath attach_recursive_mnt() transfers MNT_LOCKED from the top mount to the mount that is moved beneath it with MOVE_MOUNT_BENEATH. This allows the owner of a user namespace to replace its locked /proc or its root. The mount beneath takes on the job of covering the underlying mountpoint allowing the top mount to be unmounted. Consider two mount namespaces: (H) The host H has a shared mount P with a secret in P/d (Z) Z is a user namespace made from M. Its copy of P receives propagation from the host's P and its copy of M's cover on P/d is locked Z's owner must not get to see P/d. Now (H) mounts X on P/d. This propagates into (Z). The copy of X lands beneath (Z)'s locked cover. The locked property is transfered from (Z)'s cover to the copy of X propagated beneath it. The cover is now unlocked. Now (H) unmounts X again. The copy of X in (Z) gets unmounted and the covering mount is left unlocked on top of P/d. (Z) can now unmount it: Z: umount2(P/d) = EINVAL /* the cover is locked */ H: mount X on P/d, umount X /* both propagate into Z /* Z: umount2(P/d) = 0 /* the cover is now unlocked */ Z: read P/d/secret = "covered-by-root" /* secret revealed */ So only transfer the locked property to the mount beneath for mounts the caller has placed. A propagated copy that lands beneath a locked mount is locked as well so that the mount at the bottom of the stack carries a lock the way every check expects. The mount on top of it remains locked to ensure that it keeps covering even if the propagated mount is unmounted again. | ||||
| 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--- | ||||