Generic Crash in 1.5.0

[Google-Autofuzz]

Hello OpenJpeg,

As part of our fuzzing efforts at Google, we have identified an issue in version 1.5.0. To reproduce requires compiling the project with the LLVM compiler, taking advantage of the sanitizers that it offers (this issue was discovered using AddressSanitizer).

To reproduce you will need to build your project using that sanitizer, and execute the attached stub code on the reproducer input that we have also provided. This stub code could also serve as a useful template for fuzzing in your project with libFuzzer and/or AFL, which may help you uncover additional issues. Some documentation on how to get started with libFuzzer is here:
Getting Started Documentation (http://llvm.org/docs/LibFuzzer.html#getting-started)
LibFuzzer Tutorial (http://llvm.org/docs/LibFuzzer.html#getting-started)
OSS-Fuzz target example (https://github.com/google/oss-fuzz/blob/a143b9b39a51412d133f846688194d68fe4197ba/projects/libchewing/chewing_default_fuzzer.c)

The following options / environment variables may be necessary for accurate reproduction of the issue as well:
ASAN_OPTIONS="exitcode=1,handle_segv=1,detect_leaks=1,leak_check_at_exit=1,allocator_may_return_null=1,detect_odr_violation=0"

The sanitizer error that we encountered is here:
runtime error: value 3.40282e+38 is outside the range of representable values of type 'float'
#0 in tcd_malloc_decode_tile
#1 in j2k_read_eoc
#2 in j2k_decode_jpt_stream
#3 in DecodeAs(CODEC_FORMAT, unsigned char const*, unsigned long)
#4 in LLVMFuzzerTestOneInput
#5 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long)
#6 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long)
#7 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long)
#8 in fuzzer::FuzzerDriver(int*, char***, int ()(unsigned char const, unsigned long))
#9 in main
#10 in __libc_start_main (/usr/grte/v4/lib64/libc.so.6+0x38d77)
#11 in _start /usr/grte/v4/debug-src/glibc-2.19/csu/../sysdeps/x86_64/start.S:118

SUMMARY: AddressSanitizer: float-cast-overflow

Other relevant info/repro instructions:

We will gladly work with you so you can successfully confirm and reproduce this issue. Do let us know if you have any feedback surrounding the documentation.

Once you have reproduced the issue, we’d appreciate to learn your expected timeline for an update to be released. With any fix, please attribute the report to “Google Autofuzz project”.

We are also pleased to inform you that your project is eligible for inclusion to the OSS-Fuzz project, which can provide additional continuous fuzzing, and encourage you to investigate integration options.

Don’t hesitate to let us know if you have any questions!

Google AutoFuzz Team
poc-6e7ce47f6c5780a2c062915c7c4785d954ce0f2eb8514d1bd9e02423ee6c059e.zip

[szukw000]

@Google-Autofuzz ,

See: #882

opj_decompress -i poc-6e7ce47f6c5780a2c062915c7c4785d954ce0f2eb8514d1bd9e02423ee6c059e -o test1.png

[ERROR] Unknown input file format: poc-6e7ce47f6c5780a2c062915c7c4785d954ce0f2eb8514d1bd9e02423ee6c059e
Known file formats are *.j2k, *.jp2, *.jpc or *.jpt
The MAGIC is broken.

[rouault]

With current master :

$ bin/opj_decompress -i ../poc-6e7ce47f6c5780a2c062915c7c4785d954ce0f2eb8514d1bd9e02423ee6c059e -o out.tif
[ERROR] Unknown input file format: ../poc-6e7ce47f6c5780a2c062915c7c4785d954ce0f2eb8514d1bd9e02423ee6c059e 
        Known file formats are *.j2k, *.jp2, *.jpc or *.jpt

So no longer an issue