Base de CVEs

LibreOffice can import WMF graphics, which may be embedded in documents. A heap buffer overflow existed when importing a text record that carries its own character advance widths. The count of advance values and the length of the text were read separately from the file and were not required to agree, so drawing the text walked the advance array by character position and ran past its end when the array was the shorter of the two. In fixed versions an advance array shorter than its text is ignored.

Net::IDN::Punycode versions before 2.590 for Perl allow an out-of-bounds read via integer overflow of the delta accumulator in encode_punycode. The XS backend keeps the punycode delta, and the digit index derived from it, in a signed int. The accumulation `delta += (m-n) * (h+1)` has no overflow check, so a large enough code point wraps the delta and the digit index leaves the range of the 36-entry digit table. The bound before the final table access tests only for an index above 36, so a negative index passes it, as does 36 itself. Perl strings hold code points beyond the Unicode range, and one such code point overflows the accumulation on its own. Valid input wraps it as well, for example 1927 ASCII letters followed by U+10FFFF. The conversion functions encode a label before they check its length, so a long label reaches the encoder through the documented API. Only the XS backend is affected. Encoding an attacker-supplied string copies a byte from outside the digit table into the encoded result or crashes the process.

The Espressif ESP-hosted Wi-Fi driver (drivers/wifi/esp_hosted/) parses frames received over SPI from the ESP co-processor in esp_hosted_event_task(). For control frames it took the 16-bit TLV field data_length straight off the wire and passed it to pb_istream_from_buffer(frame.data_value, frame.data_length) without checking it against the frame length or the receive buffer. frame.data_value sits 26 bytes into a 3188-byte stack object, so a data_length of up to 0xFFFF makes pb_decode() read up to roughly 62 KB past the end of that object. Only the first fragment of a fragmented control response carries a TLV header; the pre-fix driver performed half-duplex SPI transactions and silently discarded any frame the co-processor queued while the host was transmitting (esp_hosted_hal_spi_transfer() aliased the RX buffer onto the TX buffer). When the discarded frame is the first fragment of a fragmented response, the driver treats the next fragment as a new frame — its per-fragment header and checksum are genuine, so both validation steps pass — and reads the TLV header out of raw protobuf continuation bytes. Those bytes come from control responses whose size and content an adjacent, unauthenticated attacker can influence, notably the AP scan list, which grows with the number and SSID length of access points in radio range. The impact is denial of service rather than disclosure. Reading past the end of the RAM region faults the device, and CONFIG_NANOPB_ENABLE_MALLOC is selected by the driver, so garbage length prefixes read out of bounds also drive heap allocations. The out-of-bounds bytes themselves do not reach the application: pb_decode() is started mid-stream on raw protobuf continuation bytes and so almost always fails outright, and anything that did decode would still have to pass esp_hosted_response(), which requires an exact msg_id match against the pending request, and then esp_hosted_ctrl_response(), which requires a success resp — an attacker influences the size and content of legitimate control responses, not the structure decoded out of misaligned bytes. Two related defects in the same receive path make the denial of service permanent: the fragment reassembly guard was sized with ESP_FRAME_SIZE instead of ESP_FRAME_MAX_PAYLOAD and, when tripped, returned from the sole RX thread instead of dropping the frame, and unhandled control events were queued with k_msgq_put(..., K_FOREVER) on an eight-entry queue that nothing drains, blocking that same thread. The driver has no watchdog or restart path, so either condition ends all Wi-Fi reception until the device is rebooted.

libheif is a HEIF and AVIF file format decoder and encoder. From 1.19.0 until 1.23.3, the no-icef full-item branch of unc_decoder::get_compressed_image_data_uncompressed() in libheif/codecs/uncompressed/unc_decoder.cc retains an addition-based range check that can wrap when a crafted uncompressed tile grid produces a large range_start_offset and range_size. The overflow makes the bounds comparison pass and allows heif_image_handle_decode_image_tile() to call memcpy() with an invalid source pointer and a very large length when decoding a valid high-index advertised tile. This incomplete remediation of CVE-2026-62292 can reliably crash tile-processing applications, while whole-image decoding is not claimed to reach the demonstrated path. This issue is fixed in version 1.23.3.

libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.23.2, the public heif_region_item_add_region_inline_mask_data() function in libheif/api/libheif/heif_regions.cc accepts mask_data_len without verifying that it equals the byte count required by width and height. A later heif_region_get_mask_image() call derives the read length from the region geometry, so an undersized stored buffer causes heif_region_get_inline_mask_image() to read beyond the heap allocation and copy adjacent bytes into the returned monochrome mask image. This can disclose heap data or crash an application that constructs region metadata through the writer API, while the file-parsing path is not affected because it validates the canonical mask size. This issue is fixed in version 1.23.2.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1, A truncated tga can leave a pending gif frame that is processed during output close. gifsplitpalette() computes numpixels multiplied by the palette partition width in signed 32-bit arithmetic; a large image overflows that intermediate, corrupts subpixelsa, and drives an out-of-bounds read while building the gif palette, resulting in a process crash and denial of service. The affected implementation is identified by src/gif.imageio/gif.h, GifSplitPalette(), numPixels, subPixelsA, GIFOutput, and truncated TGA input, which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1, A crafted psd with an invalid color_mode bypasses normal validation when oiio:rawcolor or psd:rawdata is enabled. psdinput::setup() then uses the attacker-controlled value to index fixed color-mode tables, causing a global out-of-bounds read and potentially a bogus allocation, resulting in denial of service. The affected implementation is identified by src/psd.imageio/psdinput.cpp, PSDInput::validate_header(), PSDInput::setup(), oiio:RawColor, psd:RawData, color_mode, and mode_channel_count, which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1, An indexed psd with transparency metadata creates fewer stored channel_buffers than the spec.nchannels value advertised by the rawcolor path. when oiio:rawcolor or psd:rawdata is enabled, psdinput::read_native_scanline() passes spec.nchannels to psdinput::interleave_row(), which indexes beyond channel_buffers, resulting in a heap out-of-bounds read and process crash. The affected implementation is identified by src/psd.imageio/psdinput.cpp, PSDInput::read_native_scanline(), PSDInput::interleave_row(), oiio:RawColor, psd:RawData, channel_buffers, and spec.nchannels, which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1, An uncompressed 16-bit iff image with a z-buffer makes iffinput::readimg() allocate a temporary scanline from m_header.rgba_count but copy from it using m_header.pixel_bytes(), whose stride also includes z-buffer bytes. the oversized memcpy reads beyond the temporary heap buffer and copies adjacent memory into the output image, resulting in a crash or disclosure of adjacent heap data. The affected implementation is identified by src/iff.imageio/iffinput.cpp, IffInput::readimg(), m_header.rgba_count, and m_header.pixel_bytes(), which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1.

gptp_mi_qualify_announce() in subsys/net/l2/ethernet/gptp/gptp_mi.c walks the Path Trace TLV of a received IEEE 802.1AS Announce message, comparing each clock identity against the local one. The loop bound was taken solely from the attacker-controlled wire field announce->steps_removed (accepted up to 254), never from announce->tlv.len, which is the field that states how many identities the TLV actually carries. Because path_sequence is the flexible member of the wire TLV (struct gptp_path_trace_tlv) and GPTP_ANNOUNCE() yields a raw pointer into the received packet buffer, the memcmp() inside the loop can address memory well past the end of the received frame. The stack's only length validation, GPTP_ANNOUNCE_CHECK_LEN(), requires the received gPTP payload to be exactly 68 + tlv.len bytes — so it does not constrain the loop, it guarantees the data is absent. An unauthenticated attacker on the same Ethernet segment can send a single Announce frame declaring tlv.len = 0 with steps_removed = 254; the frame passes the length check and reception path (net_gptp_recv() → gptp_handle_msg() → gptp_mi_qualify_announce()), which performs no authentication, and the loop then reads 255 entries of 8 bytes each — about 2 KB — beyond the end of the network buffer. The impact is an out-of-bounds read. The bytes read are only used as a memcmp() operand and are never returned to the attacker, so there is no meaningful information disclosure; the practical risk is that the overread crosses a network buffer pool boundary into unmapped or MPU-protected memory and faults the networking RX thread, causing a denial of service. Exposure is limited to builds that enable the opt-in, experimental CONFIG_NET_GPTP (TSN/AVB deployments) and to attackers with layer-2 adjacency, since gPTP frames are sent to a link-local multicast address and are not routed. The fix computes the true entry count as tlv.len / GPTP_CLOCK_ID_LEN and rejects the announce when steps_removed + 1 exceeds it, so the loop can no longer run past the data the packet-length check proved present.

Imager versions from 0.45_02 before 1.035 for Perl read outside the EXIF block via unchecked start offsets in tiff_load_ifd. tiff_load_ifd() validates an IFD entry's data by checking that `entry->offset + entry->size` stays within the EXIF block, and never checks the start offset itself. Where that sum is not the real end of the data, the check passes with the entry starting outside the block. Through 1.032 `entry->offset` is a plain int, so on the usual two's-complement implementations an offset with the high bit set converts to negative and the sum can land back inside the block. From 1.033 the field is a size_t and the addition wraps only where size_t is 32 bits. The IFD's own start offset is checked the same way and wraps where unsigned long is 32 bits, which includes 64-bit Windows. Any caller of Imager->read() on an attacker-supplied image may receive EXIF tags holding bytes from outside the block, or crash the process.

PoDoFo is a C++17 PDF manipulation library. From version 1.0.0 until 1.1.1, processing a crafted PDF with an Indexed color-space image can cause a heap out-of-bounds read in PdfColorSpaceFilterIndexed::FetchScanLine in src/podofo/main/PdfColorSpaceFilter.cpp. PODOFO_INVARIANT does not perform a runtime check, so a pixel index greater than or equal to m_MapSize can address beyond m_lookup. PdfColorSpaceFilterFactory::TryCreateFromObject also validates hival with an incorrect conjunction and no upper bound, allowing malformed Indexed color-space metadata outside the expected range. The resulting read can disclose adjacent heap data or crash the processing application. This issue is fixed in version 1.1.1.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to versions 3.0.16.0 and 3.1.11.0, processing a crafted BMP file through oiiotool or an application linked to OpenImageIO can reach BMP palette handling in src/bmp.imageio/bmpinput.cpp with an empty color table. BmpInput::read_native_scanline then performs an invalid palette read while decoding an RLE-compressed scanline, causing a process crash and denial of service. This issue is fixed in versions 3.0.16.0 and 3.1.11.0.

Out of bounds read in DataTransfer in Google Chrome prior to 153.0.8010.52 allowed a local attacker leveraging social engineering to read memory outside the sandbox via a local program. (Chromium security severity: Medium)

rabbitmq-c is a C-language AMQP client library for RabbitMQ. Prior to 0.16.0, a malicious AMQP server can send an undersized HEADER or METHOD frame during client login and cause unsigned size_t underflow in amqp_handle_input() in librabbitmq/amqp_connection.c. The parser subtracts HEADER_SIZE, fixed per-frame fields, and FOOTER_SIZE from state->target_size without first checking the minimum frame length. The wrapped encoded.len value is passed through amqp_decode_properties() to amqp_decode_table_internal(), where it defeats bounds checks and causes an out-of-bounds read and process crash. An on-path attacker can also trigger the issue when AMQP traffic is not protected by TLS with certificate validation. The demonstrated impact is denial of service, with no reliable memory disclosure or code execution shown. This issue is fixed in version 0.16.0.