| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Heap-based buffer overflow in Microsoft Standard XPS allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Microsoft Standard XPS allows an authorized attacker to elevate privileges over a network. |
| Heap-based buffer overflow in Microsoft Standard XPS allows an authorized attacker to elevate privileges locally. |
| Insufficient granularity of access control in Windows Connected User Experiences and Telemetry allows an authorized attacker to disclose information locally. |
| Integer underflow (wrap or wraparound) in Microsoft UxTheme Library (uxtheme.dll) allows an unauthorized attacker to execute code over a network. |
| Heap-based buffer overflow in Windows USB Audio Class driver (usbaudio.sys) allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Microsoft JScript allows an unauthorized attacker to execute code over a network. |
| Heap-based buffer overflow in Microsoft Standard XPS allows an authorized attacker to elevate privileges over a network. |
| Stack-based buffer overflow in Windows DHCP Client allows an unauthorized attacker to elevate privileges over an adjacent network. |
| Heap-based buffer overflow in Windows Universal Disk Format File System Driver (UDFS) allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally. |
| A flaw was found in gdk-pixbuf. This vulnerability allows a remote attacker to cause a heap out-of-bounds read by providing a specially crafted Apple Icon Image (.icns) file. The uncompress() function, which handles RLE-encoded ICNS icon data, fails to validate the source buffer's boundaries during decompression. This can lead to a denial of service, where the application crashes, or to information disclosure, potentially revealing sensitive data from adjacent memory. |
| A flaw was found in sssd, specifically within the PAM (Pluggable Authentication Modules) responder's protocol v1 parser, pam_parse_in_data(). A local client with access to the PAM responder's UNIX socket can exploit this by negotiating protocol v1 and sending an empty or truncated PAM request body. This can trigger an out-of-bounds read, potentially causing the PAM responder to terminate or restart, leading to a local denial of service. |
| A flaw was found in GNOME Shell. When processing icons from a remote search provider via D-Bus, the system fails to validate the icon's declared dimensions against the actual data buffer size. A malicious or compromised remote search provider could exploit this by providing oversized icon dimensions, leading to an out-of-bounds read. This can cause the GNOME Shell process to crash, disrupting the user's session, and potentially disclose sensitive information from adjacent memory. |
| A heap-based buffer overflow flaw was found in rpm. RPMTAG_FILESIGNATURES in a crafted, unsigned RPM package's main header is declared with the wrong header type, causing hex2binv() to allocate a one-byte buffer and then write the tag's attacker-controlled, hex-decoded content — of attacker-chosen length — past the end of that allocation. This is reachable via rpm2cpio, rpm2archive, and rpm -qlvp on an untrusted package. |
| Heap-based buffer overflow in Microsoft Office allows an unauthorized attacker to execute code locally. |
| Improper Access Control Applied to Mirrored or Aliased Memory Regions in AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to change the encryption bit for guest context pages potentially resulting in loss of integrity. |
| Improper preservation of consistency between independent representations of shared state in AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to potentially affect cache coherency for guest context pages resulting in loss of integrity. |
| The RFCOMM multiplexer control-channel handler in subsys/bluetooth/host/classic/rfcomm.c computed the echo length for a BT_RFCOMM_TEST command as buf->len - 1 and passed it to rfcomm_send_test(), whose length parameter is a uint8_t. A malformed but FCS-valid UIH frame on DLCI 0 can leave buf->len == 0 after rfcomm_handle_msg() pulls the two-byte MCC header, so buf->len - 1 underflows and narrows to 255.
rfcomm_send_test() then copies 255 bytes out of a receive buffer that holds no remaining valid data, and appends them to an outgoing L2CAP PDU allocated with only CONFIG_BT_L2CAP_TX_MTU (253 by default for CONFIG_BT_CLASSIC) bytes of tailroom. The source read runs past the end of the ACL receive buffer into adjacent buffers of the same net_buf pool, and the destination copy overruns the transmit buffer by about eight bytes; net_buf_add_mem() performs no runtime bounds check in ordinary builds, where the underlying __ASSERT_NO_MSG() is compiled out.
The trigger is a single five-byte RFCOMM frame on the multiplexer control channel, which is processed as soon as the L2CAP channel for PSM 3 is established — before any DLC exists and independent of RFCOMM session state. bt_rfcomm_init() registers that L2CAP server with .sec_level = BT_SECURITY_L1, which l2cap_br_conn_security() accepts without any link key from a peer that does not claim host Secure Simple Pairing support, so an unpaired BR/EDR device in radio range of a connectable target with CONFIG_BT_RFCOMM enabled (SPP, HFP, HSP, GOEP and similar profiles all enable it) can reach the defect.
The resulting 255-byte TEST response is transmitted back to the attacker, disclosing roughly 255 bytes of adjacent stack/pool memory — including the contents of neighbouring receive buffers, which an attacker can prime with earlier packets — and the accompanying out-of-bounds write corrupts memory following the transmit buffer, which can crash the Bluetooth host. The request is trivially repeatable, so both the disclosure and the corruption can be driven at will.
Two fixes are needed, and the first on its own does not close the out-of-bounds write. Fix 1 (0040ef781e1d, #115768) strips the FCS byte in rfcomm_recv() and echoes buf->len, rejecting anything over UINT8_MAX, which removes the underflow and the over-read. But rfcomm_make_uih_msg() still allocates the response with bt_l2cap_create_pdu() and never compares the requested length with the buffer's tailroom, so a well-formed TEST command carrying a pattern of about 248 bytes or more still builds a response (3-byte frame header, 2-byte message header, pattern, FCS) larger than the 253 bytes available. A pattern that long can only be received when the RFCOMM L2CAP receive MTU (CONFIG_BT_RFCOMM_L2CAP_MTU, which defaults to CONFIG_BT_BUF_ACL_RX_SIZE) exceeds CONFIG_BT_L2CAP_TX_MTU. The plain BR/EDR defaults (200 against 253) cannot reach it, but from v4.3.0 enabling CONFIG_BT_GOEP raises CONFIG_BT_BUF_ACL_RX_SIZE to 264 (265 from v4.4.0), so GOEP builds with only fix 1 applied still overrun the transmit buffer by up to eight bytes. This includes v4.3.2, the last v4.3 release, which carries fix 1 but will not receive fix 2. Fix 2 (214530895dd3, #118293) checks the tailroom on every RFCOMM PDU allocation and closes this residual write. |
