Windows Servicing Stack Updates Elevation of Privilege Vulnerability

Untrusted pointer dereference in Servicing Stack Updates allows an authorized attacker to elevate privileges locally.

Windows Overlay Filter Elevation of Privilege Vulnerability

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Overlay Filter allows an authorized attacker to elevate privileges locally.

Windows Print Spooler Components Elevation of Privilege Vulnerability

Use after free in Windows Print Spooler Components allows an authorized attacker to elevate privileges locally.

Windows Security Account Manager Denial of Service Vulnerability

Untrusted pointer dereference in Windows Security Account Manager allows an authorized attacker to deny service over a network.

Windows Device Association Service Elevation of Privilege Vulnerability

Untrusted pointer dereference in Windows Device Association Service allows an authorized attacker to elevate privileges locally.

Windows File Server Resource Management Service Elevation of Privilege Vulnerability

Untrusted pointer dereference in Windows File Server Resource Management Service allows an unauthorized attacker to elevate privileges with a physical attack.

Windows File Server Resource Management Service Elevation of Privilege Vulnerability

Untrusted pointer dereference in Windows File Server Resource Management Service allows an unauthorized attacker to elevate privileges with a physical attack.

DirectX Graphics Kernel Remote Code Execution Vulnerability

Untrusted pointer dereference in Windows DirectX allows an authorized attacker to execute code locally.

Windows Sensor Data Service Elevation of Privilege Vulnerability

Incorrect access of indexable resource ('range error') in Windows Sensor Data Service allows an authorized attacker to elevate privileges locally.

Windows Resilient File System (ReFS) Elevation of Privilege Vulnerability

Untrusted pointer dereference in Windows Resilient File System (ReFS) allows an authorized attacker to elevate privileges locally.

Windows Domain Controller Denial of Service Vulnerability

Untrusted pointer dereference in Windows Domain Controller allows an unauthorized attacker to deny service over a network.

Windows USB Hub Driver Elevation of Privilege Vulnerability

Untrusted pointer dereference in Windows USB Hub Driver allows an authorized attacker to elevate privileges locally.

CVE-2026-90975

A vulnerability in Realtek's RtUsbA64.sys USB audio driver allows a local, low-privileged user to abuse a kernel I/O control (IOCTL) interface that acts on a caller-supplied user-mode pointer without proper validation or capture. By issuing crafted property requests an attacker can obtain kernel-mode read and write access, which can be leveraged for local privilege escalation and arbitrary kernel code execution.

Vulnerabilities in the QNX Neutrino kernel affect QNX Software Development Platform and QNX OS for Safety

Invalid Pointer Reference in the TimerSettime() system call could allow an attacker with local access to arm a crafted timer event which can cause an information disclosure in the QNX Neutrino kernel.

Untrusted pointer dereference in the FirmwareWakingVector for the Intel(R) Slim Bootloader within Ring 0: Bare Metal OS may allow an escalation of privilege. System software adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Untrusted pointer dereference for some Hyperscan before version v5.4.2.1 within Ring 3: User Applications may allow a denial of service. Unprivileged software adversary with an unauthenticated user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (low) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Inverted memory-permission check in the RTIO syscall verifier allows a user-mode thread to read and write arbitrary kernel memory

The RTIO submission-queue verifier rtio_vrfy_sqe() in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0) accumulated the results of K_SYSCALL_MEMORY() into its valid_sqe flag with &=. That macro returns nonzero on failure (it is built on K_SYSCALL_VERIFY_MSG(), which yields !(expr)), so every buffer permission check contributed the opposite of its result. A submission whose tx.buf, rx.buf or txrx.tx_buf/txrx.rx_buf pointer was not accessible to the calling thread was accepted, while a legitimate, thread-owned buffer caused the calling thread to be killed with a kernel oops. The verifier runs on behalf of the rtio_sqe_copy_in_get_handles() system call (also reached through the inline rtio_sqe_copy_in() wrapper), so it is driven directly by untrusted user-mode input on any image built with CONFIG_USERSPACE. A user thread that has been granted an RTIO context and an rtio_iodev object — the intended usage of RTIO userspace support, established via rtio_access_grant() — can submit an SQE whose buffer pointer and length name arbitrary kernel memory; the object check on sqe->iodev is unaffected and still passes, and the crafted SQE is forwarded to the bus driver unchanged. Downstream consumers dereference the pointer with supervisor privilege. The generic I2C and I3C RTIO fallback handlers (drivers/i2c/i2c_rtio_default.c, drivers/i3c/i3c_rtio_default.c) copy sqe.rx.buf/sqe.tx.buf into struct i2c_msg and call i2c_transfer(), and the vendor SPI/I2C RTIO drivers behave equivalently. An RTIO_OP_RX submission therefore has peripheral data written into kernel memory of the attacker's choosing (arbitrary kernel write), an RTIO_OP_TX submission clocks kernel memory out over the bus (kernel memory disclosure), and a pointer to unmapped memory faults the kernel. This is a full escape from the user-mode isolation boundary that CONFIG_USERSPACE exists to enforce. The defect was masked for years because the in-tree user-mode RTIO tests only exercise RTIO_OP_NOP and mempool-backed reads, neither of which reaches the affected checks. The fix negates each K_SYSCALL_MEMORY() result and additionally validates the TXRX transmit buffer read-only, matching the SPI, I2C and I3C handlers.

Unvalidated user pointers in RTIO syscall verifiers allow a user-mode thread to write kernel memory

Two RTIO syscall verifiers, in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0), did not validate user-supplied pointers before the kernel wrote through them. z_vrfy_rtio_sqe_cancel() performed no validation at all. It passed the caller's struct rtio_sqe pointer straight to z_impl_rtio_sqe_cancel(), which converts it with CONTAINER_OF to a struct rtio_iodev_sqe, ORs RTIO_SQE_CANCELED (BIT(3)) into its 16-bit flags field in supervisor mode, then loads its next pointer and repeats until that pointer is NULL. The syscall takes no RTIO context argument, so it needs no object grant: any user-mode thread on a CONFIG_USERSPACE build can set that bit in a 16-bit word at an address of its choosing in kernel memory, and the kernel continues the write along whatever pointer chain it finds at the corresponding offset. Setting chosen bits in kernel data structures, such as object permission or thread state fields, can be used to escalate privilege from user mode. z_vrfy_rtio_sqe_copy_in_get_handles() validated its RTIO context and the input SQE array, but only NULL-checked the handle out-parameter before writing a kernel SQE pointer through it, with no K_SYSCALL_MEMORY_WRITE check. A user thread that holds a granted RTIO context can therefore make the kernel store a pointer value at an arbitrary address. The fixes validate the handle out-parameter as writable, bound the cancel handle to real submission-pool storage, and require permission on the RTIO context that owns the matching pool. Without that last check a bounded handle still let any user thread cancel submissions belonging to other contexts, silently aborting their I/O. Systems built without CONFIG_USERSPACE or without CONFIG_RTIO are unaffected.

WebDAV Elevation of Privilege Vulnerability

Untrusted pointer dereference in WebDAV allows an authorized attacker to elevate privileges locally.

net: atm: fix crash due to unvalidated vcc pointer in sigd_send()

In the Linux kernel, the following vulnerability has been resolved: net: atm: fix crash due to unvalidated vcc pointer in sigd_send() Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3