| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Out-of-bounds read in Windows NTFS allows an authorized attacker to disclose information locally. |
| Heap-based buffer overflow in Windows NTFS allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Reliable Multicast Transport Driver (RMCAST) allows an unauthorized attacker to execute code over an adjacent network. |
| Out-of-bounds read in Windows Win32K allows an authorized attacker to elevate privileges locally. |
| Stack-based buffer overflow in Windows Win32K allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows GDI+ allows an authorized attacker to execute code locally. |
| Heap-based buffer overflow in Windows DWM Core Library allows an authorized attacker to elevate privileges locally. |
| Out-of-bounds read in Windows GDI allows an authorized attacker to disclose information locally. |
| Heap-based buffer overflow in Windows Remote Access API allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows Remote Access API allows an authorized attacker to elevate privileges locally. |
| Out-of-bounds read in Windows NTFS allows an authorized attacker to disclose information locally. |
| Heap-based buffer overflow in Desktop Window Manager allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Desktop Window Manager allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows Storage Port Driver allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows Key Guard allows an authorized attacker to elevate privileges locally. |
| Out-of-bounds read in Microsoft Office allows an unauthorized attacker to disclose information locally. |
| A Heap-based Buffer Overflow vulnerability [CWE-122] vulnerability in Fortinet FortiClientWindows 7.4.0 through 7.4.3, FortiClientWindows 7.2.0 through 7.2.8 may allow an authenticated local IPSec user to execute arbitrary code or commands via "fortips_74.sys". The attacker would need to bypass the Windows heap integrity protections |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix overflow in passthrough ioctl bounds check
smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload
before copying it to userspace.
The payload offset and length both come from 32-bit fields. The bounds
check currently adds OutputOffset and qi.input_buffer_length directly, so
the addition can wrap in 32-bit arithmetic before the result is compared
against the response buffer length.
A malicious server can use a large OutputOffset and a small OutputCount
to make the wrapped sum pass the bounds check. The later copy_to_user()
then reads from io_rsp + OutputOffset, outside the response buffer.
Use size_add() for the offset plus length check so overflow is treated as
out of bounds. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_nat_sip: reload possible stale data pointer
quoting sashiko:
------------------------------------------------------------------------
[..] noticed a potential memory bug and header corruption involving the
SIP NAT helper.
In net/netfilter/nf_nat_sip.c:nf_nat_sip():
if (skb_ensure_writable(skb, skb->len)) {
nf_ct_helper_log(skb, ct, "cannot mangle packet");
return NF_DROP;
}
uh = (void *)skb->data + protoff;
uh->dest = ct_sip_info->forced_dport;
if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff,
0, 0, NULL, 0)) {
If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the
old data buffer is freed. However, nf_nat_sip() fails to update *dptr to
point to the new buffer.
It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP
packet, which would overwrite the sequence number with a checksum update.
------------------------------------------------------------------------
nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen.
But clones are possible, so rebuild dptr.
Disable nf_nat_mangle_udp_packet() branch for TCP streams.
It doesn't look like this can ever happen, else we should have received
bug reports about this, so just check the conntrack is UDP and drop
otherwise.
The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages,
so I don't think this is ever expected to be true for a TCP stream. |
| In the Linux kernel, the following vulnerability has been resolved:
net: atm: reject out-of-range traffic classes in QoS validation
Reject ATM traffic classes above ATM_ANYCLASS in check_tp().
SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so
accepting larger values leaves invalid traffic_class values in
vcc->qos.
That bad state later reaches pvc_info(), which indexes class_name[]
with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause
an out-of-bounds read when /proc/net/atm/pvc is read.
Tighten the existing QoS validation so invalid traffic_class values
are rejected at the point where user supplied QoS is accepted. |
