Headline
CVE-2020-6851: Heap buffer overflow in libopenjp2 · Issue #1228 · uclouvain/openjpeg
OpenJPEG through 2.3.1 has a heap-based buffer overflow in opj_t1_clbl_decode_processor in openjp2/t1.c because of lack of opj_j2k_update_image_dimensions validation.
Comments
rouault added a commit to rouault/openjpeg that referenced this issue
Jan 11, 2020
rouault added a commit that referenced this issue
Jan 11, 2020
opj_j2k_update_image_dimensions(): reject images whose coordinates are beyond INT_MAX (fixes #1228)
andreafioraldi added a commit to andreafioraldi/oss-fuzz that referenced this issue
Feb 17, 2021
Seems that some bugs in openjpeg can be triggered only in release mode. More specifically, I was trying to reproduce uclouvain/openjpeg#1228 using the OSS-Fuzz harness and I failed. I figured out that the bug is indeed reachable by the harness, but can be uncovered only in Release mode, otherwise, an assertion error blocks it. I guess that they use assertions only in Debug mode (WTF) and remove them in Release. So, IMO openjpeg should be fuzzed in Release mode as the configuration used in production is the one relevant for security.
inferno-chromium pushed a commit to google/oss-fuzz that referenced this issue
Feb 18, 2021
Seems that some bugs in openjpeg can be triggered only in release mode. More specifically, I was trying to reproduce uclouvain/openjpeg#1228 using the OSS-Fuzz harness and I failed. I figured out that the bug is indeed reachable by the harness, but can be uncovered only in Release mode, otherwise, an assertion error blocks it. I guess that they use assertions only in Debug mode (WTF) and remove them in Release. So, IMO openjpeg should be fuzzed in Release mode as the configuration used in production is the one relevant for security.