Total
303 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-18840 | 1 Ibm | 2 Aix, Vios | 2026-10-26 | N/A | 8.2 HIGH |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to execute arbitrary code due to improper validation of an attacker-controlled pointer. | |||||
| CVE-2026-19442 | 1 Ibm | 2 Aix, Vios | 2026-10-26 | N/A | 8.2 HIGH |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 has a pointer validation flaw exists in the AIX Virtual SCSI (vSCSI) initiator driver. Successful exploitation may result in denial of service, privilege escalation, or full compromise of the client LPAR kernel. | |||||
| CVE-2026-58596 | 1 Microsoft | 1 Edge Chromium | 2026-10-24 | N/A | 8.3 HIGH |
| Untrusted pointer dereference in Microsoft Edge (Chromium-based) allows an unauthorized attacker to elevate privileges over a network. | |||||
| CVE-2026-48340 | 3 Adobe, Apple, Microsoft | 3 Bridge, Macos, Windows | 2026-10-24 | N/A | 7.8 HIGH |
| Bridge is affected by an Untrusted Pointer Dereference vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | |||||
| CVE-2026-7406 | 1 Autodesk | 12 Advance Steel, Autocad, Autocad Architecture and 9 more | 2026-10-24 | N/A | 7.8 HIGH |
| A maliciously crafted BMP file, when parsed through certain Autodesk products, can force a Untrusted Pointer Dereference vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process. | |||||
| CVE-2026-24083 | 1 Qualcomm | 6 Qam8295p, Qam8295p Firmware, Qca6696 and 3 more | 2026-10-23 | N/A | 7.8 HIGH |
| Memory Corruption while processing IOCTL device driver requests with invalid arguments. | |||||
| CVE-2026-19676 | 2026-10-23 | N/A | 7.8 HIGH | ||
| The user-mode verifier for the peci_transfer() system call, z_vrfy_peci_transfer() in drivers/peci/peci_handlers.c, checked only the device object permission and copied the caller-supplied struct peci_msg with k_usermode_from_copy(). That copy validates the outer structure only; the buf pointers and len values inside the embedded struct peci_buf members tx_buffer and rx_buffer remained fully caller-controlled and were passed unchecked to the driver. Every in-tree PECI driver dereferences those pointers in supervisor mode: peci_npcx_transfer() in drivers/peci/peci_npcx.c and peci_it8xxx2_transfer() in drivers/peci/peci_ite_it8xxx2.c copy hardware bytes into rx_buffer.buf[i] and read command bytes out of tx_buffer.buf[i], and peci_xec_read()/peci_xec_write() in drivers/peci/peci_mchp_xec.c do the same with no bound on rx_buffer.len at all. A user-mode thread that has been granted the PECI device object — the normal way an application exposes a device under CONFIG_USERSPACE — could therefore point rx_buffer.buf at kernel data structures and have the driver write hardware-supplied bytes there, or point tx_buffer.buf at kernel memory and have its contents pushed onto the PECI/eSPI out-of-band bus. The impact is a full user-mode-to-kernel escape: an arbitrary kernel write primitive (integrity and, through it, code execution at supervisor privilege), an arbitrary kernel read disclosed to a PECI bus observer, and a trivially reachable supervisor-mode fault if an unmapped address is supplied. Exploitation requires CONFIG_USERSPACE=y, one of the PECI drivers enabled (CONFIG_PECI_NPCX, CONFIG_PECI_XEC or CONFIG_PECI_ITE_IT8XXX2), and local code execution in a user-mode thread holding the PECI device. The fix adds K_SYSCALL_MEMORY_READ() and K_SYSCALL_MEMORY_WRITE() checks over the two embedded buffers, with a size_add_overflow() guard on the frame-check-sequence byte accounted for in the RX length. | |||||
| CVE-2026-45198 | 2026-10-23 | N/A | 7.8 HIGH | ||
| Kernel software from a non-secure operating system on a platform with Trusted Execution Environment support, may cause GPU Firmware to boot up using data from non-secure memory. The GPU thread of control (Firmware) uses a pointer from non-secure memory belonging to the Rich Execution Environment (REE) when saving or retrieving internal data between the tightly coupled private memory to main memory. An attacker with control over the REE kernel may modify the pointer value, corrupting the data used by the GPU Firmware. | |||||
| CVE-2026-19023 | 2026-10-23 | N/A | N/A | ||
| Untrusted pointer dereference in the render_bin_output function in the h5dump tool in HDF5 before 2.3.0 allows attackers to cause a denial of service via a variable-length string dataset with more than one element dumped in binary mode, which corrupts the per-element stride calculation and causes subsequent elements to be read from a misaligned offset and dereferenced as a pointer. | |||||
| CVE-2026-9771 | 2026-10-23 | N/A | 8.8 HIGH | ||
| The flash_copy() system call is verified by z_vrfy_flash_copy() in drivers/flash/flash_util.c. On builds with CONFIG_USERSPACE enabled, this handler is the kernel-side trust boundary for a user-mode caller. Prior to the fix it validated only the output buffer (K_SYSCALL_MEMORY_WRITE) and passed the two struct device * arguments, src_dev and dst_dev, directly into the implementation without any object validation — unlike every sibling flash syscall, which guards its device pointer with K_SYSCALL_DRIVER_FLASH. A user-mode thread fully controls the values of src_dev/dst_dev and the contents of its own address space. The implementation z_impl_flash_copy() dereferences these pointers and calls through their driver-API function tables (e.g. api->get_parameters(dst_dev), flash_read(src_dev, ...), flash_write(dst_dev, ...)). By supplying a pointer to a forged struct device whose api table contains attacker-chosen function pointers, an unprivileged thread can cause the kernel to call arbitrary code in supervisor mode; passing any arbitrary or invalid address otherwise yields a kernel crash or out-of-bounds read. The result is a local privilege escalation out of the userspace sandbox (with kernel denial-of-service and information disclosure as lesser outcomes). The fix adds K_SYSCALL_DRIVER_FLASH(src_dev, read) and K_SYSCALL_DRIVER_FLASH(dst_dev, write) to z_vrfy_flash_copy(), which verify each device is a registered flash-driver kernel object the calling thread is permitted to use before any dereference, closing the path completely. | |||||
| CVE-2026-63924 | 1 Linux | 1 Linux Kernel | 2026-10-22 | N/A | 9.8 CRITICAL |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up. | |||||
| CVE-2026-70111 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-10-22 | N/A | 8.1 HIGH |
| Untrusted pointer dereference in Windows Kernel allows an unauthorized attacker to elevate privileges over a network. | |||||
| CVE-2026-70170 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-10-22 | N/A | 6.5 MEDIUM |
| Untrusted pointer dereference in Windows Kernel allows an authorized attacker to deny service over a network. | |||||
| CVE-2026-70104 | 1 Microsoft | 11 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 8 more | 2026-10-21 | N/A | 7.8 HIGH |
| Untrusted pointer dereference in Windows Win32 Kernel Subsystem allows an authorized attacker to elevate privileges locally. | |||||
| CVE-2026-19595 | 2026-10-20 | N/A | 6.1 MEDIUM | ||
| The user-mode syscall verifier z_vrfy_rtio_cqe_get_mempool_buffer() in subsys/rtio/rtio_syscalls.c validated its two output parameters, buff and buff_len, with K_SYSCALL_MEMORY_READ() rather than K_SYSCALL_MEMORY_WRITE(). Both are pure out-parameters: z_impl_rtio_cqe_get_mempool_buffer() stores the mempool buffer address and its length through them. The distinction is enforced by every architecture validator — arch_buffer_validate() on RISC-V PMP explicitly accepts the global __rom_region/__rodata_region for reads only, and the ARM MPU validators accept P_RO_U_RO and P_RW_U_RO regions for reads only — so a read-validated pointer is not necessarily writable by the calling thread. An unprivileged user-mode thread that has been granted access to an RTIO context (rtio_access_grant()) can invoke the rtio_cqe_get_mempool_buffer() syscall with buff/buff_len pointing at memory it may read but not write, and with a completion-queue entry whose flags field it fully controls (only RTIO_CQE_FLAG_MEMPOOL_BUFFER in flags[7:0] is required; flags[19:8] and flags[31:20] supply the block index and count). The kernel then performs a pointer-sized and a 4-byte store through those addresses while running in supervisor mode. Reaching the store requires CONFIG_USERSPACE together with CONFIG_RTIO_SYS_MEM_BLOCKS, the configuration behind RTIO_DEFINE_WITH_MEMPOOL; without the latter the implementation returns -ENOTSUP and writes nothing. Two outcomes follow. If the target lies in a memory-domain partition declared K_MEM_PARTITION_P_RW_U_RO (privileged read-write, user read-only), the kernel-mode store succeeds and deposits partly attacker-chosen values into memory the memory domain had marked read-only for that thread, bypassing the partition's write protection. If the target lies in globally readable but unwritable memory such as .text/.rodata in flash, the store faults in kernel mode; the fault is delivered to z_fatal_error() and the default k_sys_fatal_error_handler() halts or reboots the device, giving an unprivileged thread a reliable full denial of service. The read-permission check does bound the damage: the address must still be readable by the calling thread, so kernel-private memory cannot be targeted and no confidential data is disclosed. The fix replaces both checks with K_SYSCALL_MEMORY_WRITE(), so a thread lacking write permission is terminated by K_OOPS before the implementation runs; the cqe argument correctly remains read-validated. | |||||
| CVE-2026-102186 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-10-20 | N/A | 4.7 MEDIUM |
| Untrusted pointer dereference in Windows Network File System allows an authorized attacker to disclose information locally. | |||||
| CVE-2026-102188 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-10-20 | N/A | 6.8 MEDIUM |
| Untrusted pointer dereference in Windows Storage Port Driver allows an unauthorized attacker to elevate privileges with a physical attack. | |||||
| CVE-2026-108435 | 1 Microsoft | 4 365 Apps, Microsoft 365, Office 2021 and 1 more | 2026-10-20 | N/A | 6.5 MEDIUM |
| Untrusted pointer dereference in Microsoft Office Word allows an unauthorized attacker to disclose information over a network. | |||||
| CVE-2026-88219 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-10-20 | N/A | 8.8 HIGH |
| Untrusted pointer dereference in RPC Runtime allows an unauthorized attacker to execute code over a network. | |||||
| CVE-2026-64286 | 1 Linux | 1 Linux Kernel | 2026-10-19 | N/A | 8.2 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU flush_hyp_vcpu() copies the host vCPU context into the hyp's private vCPU on every run. ctxt_to_vcpu() expects a guest context to have a NULL __hyp_running_vcpu, which is only ever set on the host context, so that it resolves the vCPU via container_of(). While this is generally the case, flush_hyp_vcpu() copies the context verbatim and does not enforce this, so a value provided by the host is dereferenced at EL2 (host -> EL2). Fix by clearing __hyp_running_vcpu after the copy. | |||||