Unpredictable panic in piz/huffman when reading rgba exr file

[qarmin]

Description

When testing file - https://github.com/user-attachments/files/16202898/compressed.zip - in 100 copies with this code

use exr::prelude::*;
use walkdir::WalkDir;

fn main() {
    test()
}

pub fn test() {
    let first_arg = std::env::args().nth(1).unwrap();

    let files: Vec<_> = WalkDir::new(first_arg).max_depth(999).into_iter().flatten().filter_map(|entry| {
        if entry.file_type().is_file() {
            Some(entry.path().to_string_lossy().to_string())
        } else {
            None
        }
    }).collect();
    let mut mul_files = Vec::new();
    for file in files {
        for _ in 0..1{
            mul_files.push(file.clone());
        }
    }
    for ref file in mul_files {
            let _meta_data = MetaData::read_from_file(file, false);

            {
                let _minimal = read().no_deep_data()
                    .largest_resolution_level()
                    .rgba_channels(
                        |_size, _channels| (),
                        |_: &mut (), _position: Vec2<usize>, _pixel: (Sample, Sample, Sample, Sample)| {}
                    )
                    .first_valid_layer().all_attributes()
                    .from_file(&file);
            }

    }
}

then randomly I see this panics (~5/10% chance, so that is why I test it in multiple copies)

thread 'OpenEXR Block Decompressor Thread #6' panicked at /home/rafal/.cargo/git/checkouts/exrs-d5a098e4f3912660/e018e0d/src/compression/piz/huffman.rs:204:5:
attempt to subtract with overflow
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
^[[A
Aborted (core dumped)

Environment

• Operating System - Ubuntu 24.04
• CPU Model (Big Endian or Little Endian?) ?(default x86-64)
• EXRS Version used - Latest e018e0dba9a5a1cba3a5ddbe7a05577638fbc9e2

[johannesvollmer]

Thank you for the bug report, especially for the sample file. I'll have a look soon.

[johannesvollmer]

Do I have your permission to include and publish this image file publicly in the repository for future test runs?

[qarmin]

No(this file is probably taken from github from one project) and due random nature of this bug, I cannot reproduce problem with other files

[johannesvollmer]

understood.

[johannesvollmer]

In case you are looking for a workaround, you can try these options:

• use a different compression algorithm, in case you are the creator of the images
• disable multithreading for the exr reader and see if that prevents the error
• enable pedantic error handling if it might be the case that your files are corrupted from the harddrive
• use the native openexr bindings for rust

unfortunately, if you are using the exr crate indirectly through the image crate, these options won't be accessible currently.

[johannesvollmer]

I have good and bad news.

Good: I was able to always reproduce the problem with your file, each time when reading it. However, also none of the photo editing software I have could open it (affinity photo, krita). It seems the one file you provided is not valid, even with the official OpenEXR code.

Bad: Given that you said your original file is fine, but one of the copies is broken, it sounds like the problem might actually be your hard drive. Could some of the copies be corrupted by your system? Can you try to run your code on a different harddrive, maybe a different SSD or HDD?

[qarmin]

I wrote a little unclearly.

I downloaded the original file from the github repository, but the file that I added here is not correct.

I created a fuzzer and to test it, I tried to test the image-rs library with it.

The fuzzer tried to mess up the original image to cause crashes in the library, and that's how I found this error and created broken file.

[johannesvollmer]

Oh, you are right, sorry. The library definitely shouldn't panic for invalid files, that's correct. Sorry for the confusion. Thanks again for submitting :)