CVE-2026-102504

Wersje Imager dla Perla przed 1.036 kończą proces podczas odczytu pliku TGA z długością mapy kolorów wynoszącą 32768 lub więcej w funkcji tga_palette_read. Długość jest rozpakowywana do typu signed short, przez co wartość 32768 lub większa staje się ujemna, a następnie rzutowana na size_t, co powoduje żądanie alokacji o rozmiarze bliskim SIZE_MAX. Alokacja kończy się niepowodzeniem, a alokator Imager wywołuje exit(3).

Podatność w bibliotece Imager dla Perla przed wersją 1.033 polega na błędnym traktowaniu liczników wpisów EXIF IFD jako liczb ze znakiem, co może prowadzić do próby alokacji ogromnego bloku pamięci i awarii procesu. Atakujący może wykorzystać to, tworząc obraz z odpowiednio spreparowanymi danymi EXIF, aby przerwać działanie procesu roboczego.

Imager w wersjach przed 1.037 dla Perla przepełnia bufor sterty podczas pobierania próbek zmiennoprzecinkowych z obrazu z paletą w funkcji i_gsampf_fp. Dla obrazu z paletą funkcja getsamples() z typem "float" alokuje bufor o rozmiarze jednej próbki na piksel i pobiera do niego każdy żądany kanał każdego piksela. Żądanie więcej niż jednego kanału zapisuje poza końcem bufora. Obraz dostarczony przez atakującego kontroluje przepełniane bajty poprzez swoją paletę.

Wersje Imager dla Perla przed 1.036 ujawniają niezainicjalizowaną pamięć sterty podczas odczytu obrazu paletowego z indeksami pikseli wykraczającymi poza mapę kolorów w funkcjach i_gpix_p i i_glin_p. Paleta jest alokowana bez inicjalizacji, a czytnik TGA zapisuje indeksy pikseli bez sprawdzania ich względem mapy kolorów, co pozwala odczytać lub wyświetlić zawartość wcześniejszej pamięci sterty.

Imager w wersjach od 0.45_02 przed 1.035 dla Perla odczytuje dane poza blokiem EXIF poprzez niekontrolowane przesunięcia początkowe w funkcji tiff_load_ifd. Funkcja tiff_load_ifd() waliduje dane wpisu IFD, sprawdzając, czy suma entry->offset + entry->size mieści się w bloku EXIF, ale nigdy nie sprawdza samego przesunięcia początkowego. Gdy suma nie jest rzeczywistym końcem danych, sprawdzenie przechodzi, mimo że wpis zaczyna się poza blokiem. Do wersji 1.032 pole entry->offset jest zwykłym int, więc na typowych implementacjach dopełnienia do dwóch offset z ustawionym najstarszym bitem staje się ujemny i suma może wrócić do wnętrza bloku. Od wersji 1.033 pole jest typu size_t, a dodawanie zawija się tylko tam, gdzie size_t ma 32 bity. Własne przesunięcie początkowe IFD jest sprawdzane w ten sam sposób i zawija się tam, gdzie unsigned long ma 32 bity, co obejmuje 64-bitowy Windows. Każdy wywołujący Imager->read() na dostarczonym przez atakującego obrazie może otrzymać tagi EXIF zawierające bajty spoza bloku lub spowodować awarię procesu.

Imager w wersjach od 0.45_02 do 1.034 dla Perla może ujawnić sąsiednie bajty sterty poprzez odczyt strlen() z zerowej liczby wpisów ASCII EXIF w copy_string_tags. Atakujący może dostarczyć obraz z takim wpisem, co prowadzi do wycieku danych ze sterty do znacznika exif_*.

W bibliotece Imager dla Perla przed wersją 1.032 występuje podatność polegająca na odczycie poza dozwolonym obszarem sterty (heap out-of-bounds read) w module Imager::File::SGI. Problem dotyczy funkcji read_rgb_16_rle, która nieprawidłowo sprawdza liczbę pikseli w przebiegu RLE, co prowadzi do odczytu poza buforem. Atakujący może wykorzystać tę podatność, dostarczając spreparowany obraz SGI, co może spowodować awarię procesu.