chromium-browser: chromium-browser: Information disclosure via out-of-bounds read in Skia

Out of bounds read in Skia in Google Chrome prior to 157.0.8103.78 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)

Microsoft Office Excel Information Disclosure Vulnerability

Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to disclose information over a network.

Microsoft Office Excel Remote Code Execution Vulnerability

Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to execute code over a network.

Microsoft Office Excel Information Disclosure Vulnerability

Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to disclose information over a network.

chromium-browser: chromium-browser: Out of bounds read in Skia

Out of bounds read in Skia in Google Chrome prior to 157.0.8103.78 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High)

A out-of-bounds read vulnerability in Fortinet FortiOS 8.0.0 through 8.0.1, FortiOS 7.6.0 through 7.6.7, FortiOS 7.4.0 through 7.4.12, FortiOS 7.2.0 through 7.2.13 may allow a remote privileged attacker to execute arbitrary code or command via crafted paquets.

In GetSharedMemory of trusty_shared_memory_manager.cc, there is a possible way to trigger an out of bounds read via sign extension of a negative buffer size due to an improper or implicit cast. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.

Out‑of‑Bounds Stack Read via DMA Fill Operation

In fill of dma.rs, there is a possible way to trigger an out of bounds stack read during direct memory access fills due to a logic error. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.

chromium-browser: chromium-browser: Information disclosure via crafted HTML page

Out of bounds read in Skia in Google Chrome on on Mac prior to 157.0.8103.78 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High)

chromium-browser: chromium-browser: Information disclosure via out-of-bounds read in Skia

Out of bounds read in Skia in Google Chrome prior to 157.0.8103.78 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)

chromium-browser: chromium-browser: Out of bounds read in Media

Out of bounds read in Media in Google Chrome prior to 157.0.8103.78 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High)

Improper Back‑Channel Logout Handling in Auth0 ASP.NET Core Authentication SDK

The Auth0 ASP.NET Core Authentication SDK incorrectly determines a session's OIDC Back-Channel Logout status, which may result in a logged-out session being accepted for access to protected endpoints.

xschem 2.9.9 through 3.4.7 Out-of-Bounds Read via read_xschem_file() Embedded-Symbol Record

xschem 2.9.9 through 3.4.7 contains an out-of-bounds read vulnerability in read_xschem_file() in src/save.c that mishandles embedded-symbol records lacking a preceding instance. Attackers can supply a crafted schematic beginning with a "[" record, causing xschem to read and dereference memory below the instance array and crash.

Gcc: out-of-bounds read in std::from_chars

A flaw was found in gcc. An attacker could cause a Denial of Service (DoS) by passing a string that is not null-terminated to the std::from_chars() function in the libstdc++ library. This issue triggers an out-of-bounds read beyond the allocated buffer, potentially leading to invalid data parsing or an application crash.

Libmodulemd: libmodulemd: out-of-bounds read when emitting rpm-map artifacts

A flaw was found in libmodulemd. In the module stream v2 rpm-map emission path, an inner loop incorrectly uses the count of digest algorithms as its bound instead of the number of checksums in the current digest table. Crafted modulemd v2 metadata with multiple digest types can trigger an out-of-bounds read during YAML serialization, typically causing a crash and resulting in a denial of service.

Out-of-bounds read in Bluetooth Host periodic advertising report reassembly due to unvalidated report length

bt_hci_le_per_adv_report_common() in subsys/bluetooth/host/scan.c handles the HCI_LE_Periodic_Advertising_Report (and _v2) event. It verified that the fixed event header was present and that the controller-declared Data_Length fits the tailroom of the periodic-sync reassembly buffer, but never checked that the event actually carried as many data bytes as evt->length claims. Both reassembly paths — DATA_STATUS_PARTIAL, and DATA_STATUS_COMPLETE while a chain is already in progress — then called net_buf_simple_add_mem(&per_adv_sync->reassembly, buf->data, evt->length), copying up to 255 bytes starting past the end of the event's real payload. The Data_Length field originates in the HCI controller, so the flaw is reachable in host-only/split builds where the controller is a separate part reached over H4 UART, SPI, USB or an inter-core IPC transport: a malicious, compromised or buggy controller (or an attacker able to inject on that link) can send a report declaring a length larger than the event payload. The generic event dispatcher in subsys/bluetooth/host/hci_core.c only enforces a per-event minimum length and never cross-checks the subevent's internal length field, so nothing else catches it. Builds using Zephyr's own in-image controller are not affected, because the controller always emits a length matching the bytes it appends. Exploitation additionally requires CONFIG_BT_PER_ADV_SYNC with CONFIG_BT_PER_ADV_SYNC_BUF_SIZE > 0 (the option defaults to 0, which compiles the reassembly block out; LE Audio broadcast-sink and Public Broadcast Profile applications that reassemble fragmented periodic advertising data set it), and an established periodic advertising sync. The consequence is an out-of-bounds read of adjacent HCI RX-pool memory — including stale contents of previously received HCI events — which is copied into the reassembly buffer and then delivered to every registered bt_le_per_adv_sync_cb.recv listener as if it were received advertising data, so the disclosed memory becomes application-visible and may be forwarded off-device. The write side remains in bounds because the tailroom check uses the same length value, so there is no memory corruption; impact is limited to information disclosure and undefined behaviour on the over-read. The fix drops any report whose declared length exceeds the remaining event payload, matching the guard already present in the extended and legacy advertising report handlers.

Bluetooth Classic RFCOMM: integer underflow in the MCC TEST command handler leads to out-of-bounds read disclosed to the peer and out-of-bounds write

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.

pam_usb: Heap out-of-bounds read in pusb_get_tty_from_display_server cmdline scan

pam_usb provides hardware authentication for Linux using removable media. Prior to version 0.9.3, src/local.c (pusb_get_tty_from_display_server) allocates a 4096-byte cmdline buffer, reads up to 4096 bytes from /proc//cmdline, then replaces every NUL separator with a space. When read(2) returns exactly 4096 bytes for any process the function inspects, the buffer ends without a terminator and the subsequent strstr() calls scan past the allocation boundary. The function is invoked during normal PAM authentication when DISPLAY is set, so the read fires for every process at auth time. Consequences are bounded: strstr output is a Boolean substring match (limited info-disclosure surface) but a hostile heap layout can produce a SIGSEGV that terminates the host PAM process. This issue has been patched in version 0.9.3.

BACnet Stack: Out-of-Bounds Read in AtomicWriteFile Record Decoder via Unbounded returnedRecordCount

BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to versions 1.4.4 and 1.5.1, an out-of-bounds read vulnerability exists in bacnet-stack's AtomicWriteFile record-access path. The bug is caused by a mismatch between an externally controlled returnedRecordCount field and the fixed-size internal fileData[] array used by BACNET_ATOMIC_WRITE_FILE_DATA. This issue has been patched in versions 1.4.4 and 1.5.1.

BACnet Stack: Client-Side Out-of-Bounds Read in AtomicReadFile-ACK Record-Access Handling via RecordCount / fileData[] Mismatch

BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to versions 1.4.4 and 1.5.1, there is a client-side out-of-bounds read in the AtomicReadFile-ACK record-access handling path. The issue is caused by a mismatch between a remote returnedRecordCount value and the fixed local fileData[] array capacity in BACNET_ATOMIC_READ_FILE_DATA. The ACK decode path preserves the remote RecordCount, discards storage for excess records without truncating that count, and a downstream sink later iterates over the original RecordCount and indexes fileData[i] out of bounds. This issue has been patched in versions 1.4.4 and 1.5.1.