Validate fallback Exif offsets before parsing by acts-1631 · Pull Request #22528 · darktable-org/darktable

acts-1631 · 2026-10-06T22:34:28Z

dt_imageio_open_jpegxl() and dt_imageio_open_heif() use the first four bytes of an Exif box or item as an offset to TIFF data when falling back to blob-based metadata parsing. Their exif_size > 4 + exif_offset check can overflow for a crafted 32-bit offset, allowing a pointer outside the metadata allocation and causing an out-of-bounds read during image import. The JPEG XL path also reused the retained Exif size for later boxes.

Use subtraction-based offset validation, reject TIFF blobs too large for dt_exif_read_from_blob(), and keep JPEG XL's per-box size separate from the retained Exif allocation size. Repeated Exif boxes now replace the previous allocation safely.

HEIF and JPEG XL files store a big-endian TIFF offset at the start of their Exif payload. Adding four to an attacker-controlled uint32_t before checking the payload size can wrap and pass an out-of-range pointer to the Exif parser. Keep the JPEG XL Exif size separate from subsequent box sizes and check both loaders' offsets by subtraction. Also reject blob lengths that do not fit the Exif parser's int parameter.

victoryforce · 2026-10-07T17:24:10Z

Thanks @acts-1631 for your contribution! Proper validation to prevent OOB reads and writes is indeed important. I’ll review it soon; one thing I noticed right away: I don’t think it’s worth adding checks to the code for 32-bit platform compatibility. Leaving aside the practical value (which is zero), building darktable on actual 32-bit platforms is virtually impossible.

Use standard limits and clearer data offset names in both fallback Exif paths. Keep JPEG XL sizes in the decoder API's uint64_t domain and remove unsupported 32-bit compatibility code.

acts-1631 · 2026-10-07T20:42:21Z

Thanks for all your input.

TurboGit

Thanks!