Heap-buffer-overflow in opj_tcd_init_decode_tile

[gcode-importer]

Originally reported on Google Code with ID 420

https://code.google.com/p/chromium/issues/detail?id=425151

r2908,

Only one image fails with ASan build on MacOS x86 (all images from pdf tested).
The same image also fails with ASan build on MacOS x64.

The ASan report is not the same as chromium issue though.
Need to test all images with x64 build.

I will post more details tomorrow.

Reported by mayeut on 2014-10-22 06:05:10

---

- _Attachment: [signal_sigsegv_f65057_219_1144.pdf](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-420/comment-0/signal_sigsegv_f65057_219_1144.pdf)_

[gcode-importer]

r2911,

Only attached images not properly decoded (x86 & x64).

./bin/opj_decompress -i ../../ex/4.jp2 -o 4.bmp

[INFO] Start to read j2k main header (129).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
==59153==WARNING: AddressSanitizer failed to allocate 0x001770000270 bytes
==59153==AddressSanitizer's allocator is terminating the process instead of returning
0
==59153==If you don't like this behavior set allocator_may_return_null=1
==59153==AddressSanitizer CHECK failed: /private/tmp/llvm-release/final/llvm.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:149
"((0)) != (0)" (0x0, 0x0)
    #0 0x1043e15b3 in __asan::AsanCheckFailed(char const*, int, char const*, unsigned
long long, unsigned long long) (/Users/Matt/Dev/llvm-clang-3.5.0-macosx-apple-darwin/lib/clang/3.5.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x345b3)
    #1 0x1043e4c41 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned
long long, unsigned long long) (/Users/Matt/Dev/llvm-clang-3.5.0-macosx-apple-darwin/lib/clang/3.5.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x37c41)

Reported by mayeut on 2014-10-22 21:53:14

---

- _Attachment: [4.jp2](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-420/comment-1/4.jp2)_

[gcode-importer]

This patch has been verified against the whole test suite with no regressions.
It checks for an illegal 0 custom precinct exponent for resolutions different than
0 (As per ISO 15444-1)

With a correct value of 8, the image decodes properly. With every other possible value
(1->7, 9->15), the image either gets decked with artefacts or fails to decode gracefully
(no ASan error)

./bin/opj_decompress -i ../../data/issue420/4.jp2 -o 0.bmp

[INFO] Start to read j2k main header (129).
[ERROR] Invalid precinct size
[ERROR] Error reading COD marker
[ERROR] Marker handler function failed to read the marker segment
ERROR -> opj_decompress: failed to read the header

Reported by mayeut on 2014-10-24 20:11:16

• Status changed: Verified

---

- _Attachment: [issue420.patch](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-420/comment-2/issue420.patch)_

[gcode-importer]

@antonin, has this patch been committed?

Reported by [email protected] on 2014-10-29 17:08:56

[gcode-importer]

This issue was closed by revision r2920.

Reported by detonin on 2014-10-30 18:00:54

• Status changed: Fixed