crash: assertion `left == right` failed for JPEG

[TheOneric]

I stumbled into a crash from a failed assertion on current dev (b3b244d) while running the fuzzer a bit

thread '<unnamed>' panicked at /home/gekota/img-fuzz/zune-image/crates/zune-jpeg/src/upsampler/scalar.rs:59:5:
assertion `left == right` failed
  left: 512
 right: 256

stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.80.1/library/std/src/panicking.rs:652:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.80.1/library/core/src/panicking.rs:72:14
   2: core::panicking::assert_failed_inner
             at /usr/src/rustc-1.80.1/library/core/src/panicking.rs:408:17
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.80.1/library/core/src/panicking.rs:363:5
   4: zune_jpeg::upsampler::scalar::upsample_vertical
   5: zune_jpeg::upsampler::scalar::upsample_hv
             at ./src/upsampler/scalar.rs:83:5
   6: zune_jpeg::worker::upsample
             at ./src/worker.rs:402:21
   7: zune_jpeg::mcu::<impl zune_jpeg::decoder::JpegDecoder<T>>::post_process
             at ./src/mcu.rs:418:17
   8: zune_jpeg::mcu::<impl zune_jpeg::decoder::JpegDecoder<T>>::decode_mcu_ycbcr_baseline
             at ./src/mcu.rs:201:13
   9: zune_jpeg::decoder::JpegDecoder<T>::decode_into
             at ./src/decoder.rs:712:13
  10: zune_jpeg::decoder::JpegDecoder<T>::decode
             at ./src/decoder.rs:209:9
  11: decode_buffer::_::__libfuzzer_sys_run
             at ./fuzz/fuzz_targets/decode_buffer.rs:9:13

Minimised test file: zune-jpeg_assertfail.jpg
Even if the file is invalid (likely, but not sure), it probably shouldn't lead to an outright, ungraceful crash.

[etemesi254]

Correct, it should not crash.

Looking into it

[richard-viney]

I just ran into what appears to be the same or very similar crash when fuzzing a library that depends on zune-jpeg 0.4.14.

If it's helpful, the JPEG file that triggers the issue is here: https://drive.google.com/file/d/1azRp3lT9GAO0JhGCyTTvulaVjUU5_sqQ/view?usp=sharing

[etemesi254]

Hi, Could you try the latest version? Kind regards, Caleb

…

On Wed, 26 Mar 2025 at 15:44, Richard Viney ***@***.***> wrote: I just ran into what appears to be the same or very similar crash when fuzzing a library that depends on zune-jpeg 0.4.14. If it's helpful, the JPEG file that triggers the issue is here: https://drive.google.com/file/d/1azRp3lT9GAO0JhGCyTTvulaVjUU5_sqQ/view?usp=sharing — Reply to this email directly, view it on GitHub <#236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFZRVEYNQY23QTCYXYKIEB32WKOKFAVCNFSM6AAAAABOU5FWTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJUGI3TKOJXHA> . You are receiving this because you commented.Message ID: ***@***.***> [image: richard-viney]*richard-viney* left a comment (etemesi254/zune-image#236) <#236 (comment)> I just ran into what appears to be the same or very similar crash when fuzzing a library that depends on zune-jpeg 0.4.14. If it's helpful, the JPEG file that triggers the issue is here: https://drive.google.com/file/d/1azRp3lT9GAO0JhGCyTTvulaVjUU5_sqQ/view?usp=sharing — Reply to this email directly, view it on GitHub <#236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFZRVEYNQY23QTCYXYKIEB32WKOKFAVCNFSM6AAAAABOU5FWTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJUGI3TKOJXHA> . You are receiving this because you commented.Message ID: ***@***.***>

[richard-viney]

The panic is also present on latest main (4a073b1).

I found another panic in 0.4.14 during fuzzing, but that one doesn't reproduce on main so I won't open an issue for it. (Unless you'd like it to be added as a test case?)

[richard-viney]

I've made a fork here that prevents the panic, but I don't think it's the correct solution because other readers seem to manage, i.e. I think this may be something zune-jpeg should handle, and it's not simply a panic on an invalid JPEG file.

It appears to be related to interleaved JPEGs that need vertical upsampling. The initial panic is related to the scratch buffer not being the expected size. This can be fixed by making it larger and then providing a slice of the required size. But then a second assert is triggered by the following code in mcu.rs because the samples are inconsistent:

                    // ensure length matches for all samples
                    let first_len = samples[0].len();
                    for samp in samples.iter().take(comp_len) {
                        assert_eq!(first_len, samp.len());
                    }

I haven't dug any deeper at this stage.

---

Here are two relevant JPG files created during fuzzing for reproduction purposes:

• https://drive.google.com/file/d/1azRp3lT9GAO0JhGCyTTvulaVjUU5_sqQ/view?usp=share_link
• https://drive.google.com/file/d/1f8wBANcLSSjJervW9APiVswJam4yx4ti/view?usp=sharing

Interestingly the first one renders differently in Safari vs Chrome on macOS:

Safari gives:

But Chrome gives: