Vulnerabilidades do HappySeaFox Sail

SAIL is a cross-platform library for loading and saving images with support for animation, metadata, and ICC profiles. In 0.9.10 and earlier, psd_private_sail_pixel_format() in src/sail-codecs/psd/helpers.c resolves a one-channel PSD in Bitmap color mode to SAIL_PIXEL_FORMAT_BPP1_INDEXED without requiring the file depth to be one, so the pixel buffer uses one-bit rows while sail_codec_load_frame_v8_psd() in src/sail-codecs/psd/psd.c accepts depth == 8 and writes one attacker-controlled byte per pixel. Loading a crafted PSD through sail_load_from_file() or sail_load_from_memory() therefore writes beyond each heap row, causing memory corruption, a reliable crash, or potential code execution. This mode/depth mismatch is distinct from GHSA-rcqx-gc76-r9mv and GHSA-wcj8-hxxf-pq2c. This issue is fixed in version 1.0.0.

SAIL is a cross-platform library for loading and saving images with support for animation, metadata, and ICC profiles. In 0.9.10 and earlier, the TGA_INDEXED_RLE path selected by image_type == 9 allocates an image buffer using the one-byte-per-pixel SAIL_PIXEL_FORMAT_BPP8_INDEXED format returned by tga_private_sail_pixel_format() in src/sail-codecs/tga/helpers.c, while sail_codec_load_frame_v8_tga() in src/sail-codecs/tga/tga.c derives a two-to-four-byte pixel_size from an attacker-controlled header bpp value from 9 through 32. Loading a crafted color-mapped run-length-encoded TGA through sail_load_from_file() or sail_load_from_memory() therefore writes attacker-controlled bytes beyond the heap pixel buffer. The pixel-count clamp added for CVE-2026-40494 does not constrain the per-pixel write width, so this issue is an incomplete fix of that vulnerability and can cause heap corruption, a reliable crash, or potential code execution. This issue is fixed in version 1.0.0.

SAIL é uma biblioteca multiplataforma para carregar e salvar imagens, com suporte a animação, metadados e perfis ICC. Antes do commit 45d48d1f2e8e0d73e80bc1fd5310cb57f4547302, o decodificador RLE do codec TGA em tga.c apresenta uma vulnerabilidade de verificação de limites assimétrica. O caminho de pacotes de execução (linha 297) limita corretamente a contagem de repetições ao espaço restante do buffer, mas o caminho de pacotes brutos (linhas 305-311) não possui verificação equivalente. Isso permite escrever até 496 bytes de dados controlados pelo atacante além do fim de um buffer na heap. O commit 45d48d1f2e8e0d73e80bc1fd5310cb57f4547302 corrige o problema.

SAIL is a cross-platform library for loading and saving images with support for animation, metadata, and ICC profiles. Prior to commit c930284445ea3ff94451ccd7a57c999eca3bc979, the PSD codec computes bytes-per-pixel (`bpp`) from raw header fields `channels * depth`, but the pixel buffer is allocated based on the resolved pixel format. For LAB mode with `channels=3, depth=16`, `bpp = (3*16+7)/8 = 6`, but the format `BPP40_CIE_LAB` allocates only 5 bytes per pixel. Every pixel write overshoots, causing a deterministic heap buffer overflow on every row. Commit c930284445ea3ff94451ccd7a57c999eca3bc979 contains a patch.

SAIL é uma biblioteca multiplataforma para carregar e salvar imagens, com suporte a animação, metadados e perfis ICC. Antes do commit 36aa5c7ec8a2bb35f6fb867a1177a6f141156b02, o codec XWD resolve o formato de pixel com base em `pixmap_depth`, mas o código de troca de bytes usa `bits_per_pixel` de forma independente. Quando `pixmap_depth=8` (BPP8_INDEXED, buffer de 1 byte por pixel), mas `bits_per_pixel=32`, o laço de troca de bytes acessa a memória como `uint32_t*`, lendo/escrevendo 4x o tamanho do buffer alocado. Esta é uma vulnerabilidade diferente da GHSA-3g38-x2pj-mv55 (CVE-2026-27168) reportada anteriormente, que tratava da validação de `bytes_per_line`. O commit 36aa5c7ec8a2bb35f6fb867a1177a6f141156b02 contém um patch.

SAIL is a cross-platform library for loading and saving images with support for animation, metadata, and ICC profiles. All versions are vulnerable to Heap-based Buffer Overflow through the XWD parser's use of the bytes_per_line value. The value os read directly from the file as the read size in io->strict_read(), and is never compared to the actual size of the destination buffer. An attacker can provide an XWD file with an arbitrarily large bytes_per_line, causing a massive write operation beyond the buffer heap allocated for the image pixels. The issue did not have a fix at the time of publication.