| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Untrusted pointer dereference in Microsoft Office Excel allows an unauthorized attacker to execute code locally. |
| Untrusted pointer dereference in Microsoft Office Excel allows an unauthorized attacker to execute code locally. |
| Untrusted pointer dereference in Windows HTTP.sys allows an authorized attacker to elevate privileges locally. |
| Untrusted pointer dereference in Windows HTTP.sys allows an authorized attacker to elevate privileges locally. |
| Improper input validation in the AMD Graphics Driver could allow an attacker to supply a specially crafted pointer, potentially leading to arbitrary writes or denial of service. |
| Software installed and run as a non-privileged user may conduct improper GPU system calls to trigger a crash of the FW running on the GPU freezing graphics output. |
| Improper syscall input validation in ASP (AMD Secure Processor) may force the kernel into reading syscall parameter values from its own memory space allowing an attacker to infer the contents of the kernel memory leading to potential information disclosure. |
| A memory corruption vulnerability in SdHost and SdMmcDevice in Insyde InsydeH2O kernel 5.2 before 05.29.09, kernel 5.3 before 05.38.09, kernel 5.4 before 05.46.09, kernel 5.5 before 05.54.09, and kernel 5.6 before 05.61.09 could lead to escalating privileges in SMM. |
| There is an elevation of privilege vulnerability in server
and client components of Absolute Secure Access prior to version 13.07.
Attackers with local access and valid desktop user credentials can elevate
their privilege to system level by passing invalid address data to the vulnerable
component. This could be used to
manipulate process tokens to elevate the privilege of a normal process to
System. The scope is changed, the impact to system confidentiality and
integrity is high, the impact to the availability of the effected component is
none. |
| Untrusted Pointer Dereference in I/O subsystem for some Intel(R) QAT software before version 2.0.5 may allow authenticated user to potentially enable information disclosure via local operating system access. |
| Untrusted pointer dereference for some Intel(R) Graphics Drivers may allow an authenticated user to potentially enable escalation of privilege via local access. |
| Untrusted pointer dereference in UEFI firmware for some Intel(R) reference processors may allow a privileged user to potentially enable escalation of privilege via local access. |
| Untrusted pointer dereference in some Intel(R) Graphics Drivers may allow an authenticated user to potentially enable escalation of privilege via local access. |
| Untrusted pointer dereference in Microsoft Office allows an unauthorized attacker to execute code locally. |
| Untrusted pointer dereference in Microsoft Office Excel allows an unauthorized attacker to execute code locally. |
| 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 |
| Untrusted Pointer Dereference vulnerability in RTI Connext Professional (Core Libraries) allows Pointer Manipulation.This issue affects Connext Professional: from 7.4.0 before 7.6.0, from 7.0.0 before 7.3.0.10, from 6.1.0 before 6.1.2.27, from 6.0.0 before 6.0.1.43, from 5.3.0 before 5.3.*, from 4.4a before 5.2.*. |
| Memory corruption while doing Escape call when user provides valid kernel address in the place of valid user buffer address. |
| Memory corruption occurs during an Escape call if an invalid Kernel Mode CPU event and sync object handle are passed with the DriverKnownEscape flag reset. |
| Microsoft Excel Remote Code Execution Vulnerability |
