Heap-double-free in j2k_read_ppm_v3

[gcode-importer]

Originally reported on Google Code with ID 393

 issue 414089: Heap-double-free in j2k_read_ppm_v3
    http://code.google.com/p/chromium/issues/detail?id=414089

Reported by detonin on 2014-09-17 09:09:34

[gcode-importer]

Reported by detonin on 2014-09-17 09:17:09

• Labels added: OpjVersion-2.x

[gcode-importer]

Reproduced on trunk r2885

./bin/opj_decompress -i ../../data/issue393/0.jp2 -o 0.bmp

[INFO] Start to read j2k main header (119).
=================================================================
==33685==ERROR: AddressSanitizer: attempting double-free on 0x01e007f0 in thread T0:
    #0 0x309f84 in wrap_free (/Users/Matt/Dev/llvm-clang-3.5.0-macosx-apple-darwin/lib/clang/3.5.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x2ff84)
    #1 0x7d8d37 in j2k_read_ppm_v3 /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:3662:33
    #2 0x7fc174 in opj_j2k_read_header_procedure /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:7132:23
    #3 0x7e2f27 in opj_j2k_exec /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:7187:41
    #4 0x7e2bbd in opj_j2k_read_header /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:6719:15
    #5 0x8073bc in opj_jp2_read_header /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/jp2.c:2310:9
    #6 0x80de79 in opj_read_header /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/openjpeg.c:391:10
    #7 0xa5613 in main /Users/Matt/Dev/OpenJpeg/issue391/src/bin/jp2/opj_decompress.c:801:8
    #8 0x94511700 in start (/usr/lib/system/libdyld.dylib+0x3700)
    #9 0x4 (<unknown module>)

0x01e007f0 is located 0 bytes inside of 1-byte region [0x01e007f0,0x01e007f1)
freed by thread T0 here:
    #0 0x30a13a in wrap_realloc (/Users/Matt/Dev/llvm-clang-3.5.0-macosx-apple-darwin/lib/clang/3.5.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x3013a)
    #1 0x7d87b9 in j2k_read_ppm_v3 /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:3660:53
    #2 0x7fc174 in opj_j2k_read_header_procedure /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:7132:23
    #3 0x7e2f27 in opj_j2k_exec /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:7187:41
    #4 0x7e2bbd in opj_j2k_read_header /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:6719:15
    #5 0x8073bc in opj_jp2_read_header /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/jp2.c:2310:9
    #6 0x80de79 in opj_read_header /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/openjpeg.c:391:10
    #7 0xa5613 in main /Users/Matt/Dev/OpenJpeg/issue391/src/bin/jp2/opj_decompress.c:801:8
    #8 0x94511700 in start (/usr/lib/system/libdyld.dylib+0x3700)
    #9 0x4 (<unknown module>)

previously allocated by thread T0 here:
    #0 0x30a30a in wrap_calloc (/Users/Matt/Dev/llvm-clang-3.5.0-macosx-apple-darwin/lib/clang/3.5.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x3030a)
    #1 0x7d838e in j2k_read_ppm_v3 /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:3572:47
    #2 0x7fc174 in opj_j2k_read_header_procedure /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:7132:23
    #3 0x7e2f27 in opj_j2k_exec /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:7187:41
    #4 0x7e2bbd in opj_j2k_read_header /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:6719:15
    #5 0x8073bc in opj_jp2_read_header /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/jp2.c:2310:9
    #6 0x80de79 in opj_read_header /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/openjpeg.c:391:10
    #7 0xa5613 in main /Users/Matt/Dev/OpenJpeg/issue391/src/bin/jp2/opj_decompress.c:801:8
    #8 0x94511700 in start (/usr/lib/system/libdyld.dylib+0x3700)
    #9 0x4 (<unknown module>)

SUMMARY: AddressSanitizer: double-free ??:0 wrap_free
==33685==ABORTING

Reported by mayeut on 2014-09-20 13:18:46

---

- _Attachment: [0.jp2](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-393/comment-2/0.jp2)_

[gcode-importer]

Double free is due to the use of realloc with new size == 0.

I think there's code like this everywhere. What should we do ? (for now, the patch
only deals with this specific issue...)
We could modify opj_realloc behavior not to be the same as realloc (this could be confusing...)
in case size == 0, return NULL without freeing input pointer.

with patch :
./bin/opj_decompress -i ../../data/issue393/0.jp2 -o 0.bmp

[INFO] Start to read j2k main header (119).
[ERROR] Not enough memory to increase the size of ppm_data to add the new (complete)
Ippm series
[ERROR] Marker handler function failed to read the marker segment
ERROR -> opj_decompress: failed to read the header

Reported by mayeut on 2014-09-20 14:37:52

---

- _Attachment: [issue393.patch](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-393/comment-3/issue393.patch)_

[gcode-importer]

Antonin,

We might to modify this. If I'm not mistaken, l_N_ppm == 0, this is probably not allowed
?

Reported by mayeut on 2014-09-27 13:19:16

[gcode-importer]

+ cc Bo Xu from Foxit 

... so that you can follow what happens on these issues.

Reported by detonin on 2014-09-28 21:18:37

[gcode-importer]

kdu_expand -i ../../data/issue393/0.jp2 -o 0.bmp
Kakadu Core Error:
Found multiple PPM/PPT marker segments with identical Zppt/Zppm indices within
the same header scope (main or tile-part header)!

Reported by mayeut on 2014-09-30 19:49:39

[gcode-importer]

Previous patch still left a memory leak. This one doesn't. OK in CDash.

Reported by mayeut on 2014-10-05 20:56:32

---

- _Attachment: [issue393.patch](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-393/comment-7/issue393.patch)_

[gcode-importer]

./bin/opj_decompress -i ../../data/issue393/0.jp2 -o 0.bmp

[INFO] Start to read j2k main header (119).
[ERROR] Zppm O already processed. Found twice.
[ERROR] Marker handler function failed to read the marker segment
ERROR -> opj_decompress: failed to read the header

Reported by mayeut on 2014-10-05 21:01:14

[gcode-importer]

Reported by mayeut on 2014-10-07 20:01:28

• Status changed: Verified

[gcode-importer]

Thanks Matthieu.

Regarding comment #3 about changing the behaviour of opj_realloc, what shall we do
?

Reported by detonin on 2014-10-21 12:23:34

[gcode-importer]

This issue was closed by revision r2904.

Reported by detonin on 2014-10-21 12:28:09

• Status changed: Fixed