[rootvector2]

Description

jpegli_save_markers only rejects marker_code < 0xe0 before writing m->markers_to_save_[marker_code - 0xe0], a uint8_t[32] that covers 0xe0..0xff. Any marker_code > 0xff passes the guard and writes a byte at an attacker-chosen positive offset past the array in the heap-allocated jpeg_decomp_master (ASan reports a heap-buffer-overflow WRITE of size 1 for marker_code = 0x10000). Reachable through both this entry point and the libjpeg-compatible jpeg_save_markers wrapper.

Found by comparing this setter against its sibling jpegli_set_marker_processor and jpegli_write_m_header, which both bound the code from above, and libjpeg's jdmarker.c, which rejects unknown codes with JERR_UNKNOWN_MARKER. The fix adds the missing upper bound at the array size, so every code that was previously in range is still accepted. Added a DecoderErrorHandlingTest that passes 0x100 and expects a clean error; it fails before the fix and passes after.

Pull Request Checklist

• CLA Signed: Have you signed the Contributor License Agreement (individual or corporate, as appropriate)? Only contributions from signed contributors can be accepted.
• Authors: Have you considered adding your name to the AUTHORS file?
• Code Style: Have you ensured your code adheres to the project's coding style guidelines? You can use ./ci.sh lint for automatic code formatting.