imgproxy ICOローダーの境界外書き込みで認証不要のワーカークラッシュ

Summary

Out-of-bounds heap write in imgproxy's ICO loader (vips/icoload.c): when the ICO entry's image data buffer is small, the loader's BMP-header-reconstruction writes land past the allocation, corrupting the size field of the following heap chunk. The worker then aborts deterministically (glibc munmap_chunk(): invalid pointer → SIGABRT → Go panic, exit code 2).

Details

In vips_foreign_load_ico_header in vips/icoload.c, after the ICO entry's image data is read into a heap buffer of data_size + 14 bytes, the loader reconstructs a BMP file header in front of it using fields read from the ICO's internal BITMAPINFOHEADER:

uint32_t num_colors = GUINT32_FROM_LE(*(uint32_t *) (actual_data + 32));  // unvalidated
uint16_t bpp        = GUINT16_FROM_LE(*(uint16_t *) (actual_data + 14));  // unvalidated

if ((num_colors == 0) && (bpp <= 8))
  pix_offset = BMP_FILE_HEADER_LEN + BMP_BITMAP_INFO_HEADER_LEN + 4 * (1 << bpp);
else
  pix_offset = BMP_FILE_HEADER_LEN + BMP_BITMAP_INFO_HEADER_LEN + 4 * num_colors;

int32_t height = GINT32_FROM_LE(*(int32_t *) (actual_data + 8));  // readable past the buffer
height = height / 2;

With a crafted entry declaring a tiny data_size (e.g. 1 byte), all of these reads (offsets +8, +14, +32) go past the allocation, and the reconstructed-header writes land past the end of the buffer — specifically a 32-bit height/2-derived value at alloc+22..+25, overwriting the LSBs of the size field of the physical…