CVE-2020-6851

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.

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.

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.

OpenJPEG is an open-source JPEG 2000 codec written in C language. It has been developed in order to promote the use of JPEG 2000, a still-image compression standard from the Joint Photographic Experts Group (JPEG). Since April 2015, it is officially recognized by ISO/IEC and ITU-T as a JPEG 2000 Reference Software.

Security Fix(es):

A flaw was found in OpenJPEG’s encoder. This flaw allows an attacker to pass specially crafted x,y offset input to OpenJPEG to use during encoding. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.(CVE-2020-27823)

A flaw was found in OpenJPEG’s encoder in the opj_dwt_calc_explicit_stepsizes() function. This flaw allows an attacker who can supply crafted input to decomposition levels to cause a buffer overflow. The highest threat from this vulnerability is to system availability.(CVE-2020-27824)

opj_t1_clbl_decode_processor in openjp2/t1.c in OpenJPEG 2.3.1 through 2020-01-28 has a heap-based buffer overflow in the qmfbid==1 case, a different issue than CVE-2020-6851.(CVE-2020-8112)

AOpenJPEG 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.(CVE-2020-6851)

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.

Updated openjpeg2 packages fix security vulnerability:

OpenJPEG through 2.3.1 has a heap-based buffer overflow in opj_t1_clbl_decode_processor in libopenjp2.so (CVE-2020-6851).

These are all security issues fixed in the libopenjp2-7-2.4.0-1.4 package on the GA media of openSUSE Tumbleweed.

These are all security issues fixed in the gdk-pixbuf-loader-libheif-1.23.5-1.1 package on the GA media of openSUSE Tumbleweed.

This update for libheif fixes the following issues:

• CVE-2026-84449: hOp_RGB24_32_to_YCbCr Memory Access Error / SEGV (bsc#1281829).
• AV1/libaom path allows allocation before libheif rejects mismatched coded dimensions (bsc#1281953).
• Caller-configured security limits not enforced for MINI-box parsing (bsc#1281952).
• Heap out-of-bounds read in libheif alpha compositing via mismatched per-channel bit depths (bsc#1281951).
• Heap-use-after-free and double free in ImageItem::encode_to_bitstream_and_boxes (bsc#1281949).
• Incomplete OpenJPEG pre-decode security limits allow unsafe decode through the public API (bsc#1281954).
• JPEG 2000 pclr zero-column allocation amplification bypasses max_total_memory (bsc#1281950).
• Out-of-bounds heap read in unc_encoder_rgb_pixel_interleave (bsc#1281948).

Changes for libheif:

• update to 1.23.5:

• (GHSA-v8qw-hwjv-44hw) Memory exhaustion through a mismatch between the container and the bitstream image size. A crafted image can declare a small size in its ispe property while the bitstream declares a much larger coded frame. The container-level checks used the ispe size, so the oversized bitstream reached the decoder, which allocated a frame buffer for the in-band size before libheif rejected the mismatch. The advisory demonstrated this for AV1 with the libaom backend (a 351-byte AVIF declaring 64x64 but coding up to 27648x27648, allocating hundreds of MB to more than 10 GB), but the same class affects every codec whose real frame size lives in the bitstream. The coded size is now checked against max_image_size_pixels in the codec- independent decode path, before any bytes reach a decoder plugin: all AV1 sequence headers, all HEVC/AVC/VVC SPS NAL units (including those carried in the item data, not only the ones in the configuration record), the JPEG SOF marker and the JPEG 2000 SIZ reference grid are scanned for the largest coded size. (high)
• (GHSA-qwpf-5wf7-r996) Heap use-after-free and double free when encoding an image that carries a TAI timestamp, including transcoding a file with an itai property. ImageDescription shallow-copied its raw heif_tai_timestamp_packet pointer, and a temporary in ImageItem::encode_to_bitstream_and_boxes() freed the packet while the item and the source image still held it. The timestamp is now stored by value. (medium)
• (GHSA-9c75-9g8r-4728) Memory amplification through a JPEG 2000 pclr box declaring zero palette columns. The entry-count bound was skipped for zero columns, so an 11-byte box allocated 65,535 empty palette entries, and nested j2kH containers could repeat this within the child and nesting limits: a 3 KB file reached about 330 MB RSS, none of it charged to max_total_memory. Zero columns are rejected (ISO/IEC 15444-1 requires 1 to 255), the byte bound is unconditional, and the palette storage is charged to the memory limits. (medium)
• (GHSA-r7gr-2xm2-23wf) Heap out-of-bounds read in alpha compositing for uncompressed (unci) images whose colour planes have different bit depths. Op_flatten_alpha_plane read every plane through the sample type of the first colour plane, so an 8-bit blue plane next to 16-bit red and green planes was read with a halved stride past its end, and the bytes ended up in the composited output. ColorState now tracks one bit depth per plane, and the operator declines mixed sample widths at planning time. (medium)
• (GHSA-q492-cfcm-895h) The OpenJPEG decoder plugin's pre-decode size check bounded the JPEG 2000 window span (x1-x0)*(y1-y0) but not the absolute reference-grid coordinates, so a codestream with a 17-pixel window on a grid near the 32-bit boundary reached opj_decode(). Against OpenJPEG 2.3.1 this produced a heap-buffer-overflow write inside OpenJPEG (the class of CVE-2020-6851); OpenJPEG 2.5.4 rejects the input. The reference-grid area is now bounded as well. (low)
• (GHSA-qfj5-c4pq-q998) Heap out-of-bounds read in the uncompressed encoder when an…

This update for openjpeg2 fixes the following issues:

• CVE-2018-5727: Fixed integer overflow vulnerability in theopj_t1_encode_cblks function (bsc#1076314).
• CVE-2018-5785: Fixed integer overflow caused by an out-of-bounds leftshift in the opj_j2k_setup_encoder function (bsc#1076967).
• CVE-2018-6616: Fixed excessive iteration in the opj_t1_encode_cblks function of openjp2/t1.c (bsc#1079845).
• CVE-2018-14423: Fixed division-by-zero vulnerabilities in the functions pi_next_pcrl, pi_next_cprl,and pi_next_rpcl in lib/openjp3d/pi.c (bsc#1102016).
• CVE-2018-16375: Fixed missing checks for header_info.height and header_info.width in the function pnmtoimage in bin/jpwl/convert.c (bsc#1106882).
• CVE-2018-16376: Fixed heap-based buffer overflow function t2_encode_packet in lib/openmj2/t2.c (bsc#1106881).
• CVE-2018-20845: Fixed division-by-zero in the functions pi_next_pcrl, pi_next_cprl, and pi_next_rpcl in openmj2/pi.ci (bsc#1140130).
• CVE-2020-6851: Fixed heap-based buffer overflow in opj_t1_clbl_decode_processor (bsc#1160782).
• CVE-2020-8112: Fixed heap-based buffer overflow in opj_t1_clbl_decode_processor in openjp2/t1.c (bsc#1162090).
• CVE-2020-15389: Fixed use-after-free if t a mix of valid and invalid files in a directory operated on by the decompressor (bsc#1173578).
• CVE-2020-27823: Fixed heap buffer over-write in opj_tcd_dc_level_shift_encode() (bsc#1180457).
• CVE-2021-29338: Fixed integer overflow that allows remote attackers to crash the application (bsc#1184774).
• CVE-2022-1122: Fixed segmentation fault in opj2_decompress due to uninitialized pointer (bsc#1197738).

This update for libheif fixes the following issues:

• CVE-2026-84449: hOp_RGB24_32_to_YCbCr Memory Access Error / SEGV (bsc#1281829).
• AV1/libaom path allows allocation before libheif rejects mismatched coded dimensions (bsc#1281953).
• Caller-configured security limits not enforced for MINI-box parsing (bsc#1281952).
• Heap out-of-bounds read in libheif alpha compositing via mismatched per-channel bit depths (bsc#1281951).
• Heap-use-after-free and double free in ImageItem::encode_to_bitstream_and_boxes (bsc#1281949).
• Incomplete OpenJPEG pre-decode security limits allow unsafe decode through the public API (bsc#1281954).
• JPEG 2000 pclr zero-column allocation amplification bypasses max_total_memory (bsc#1281950).
• Out-of-bounds heap read in unc_encoder_rgb_pixel_interleave (bsc#1281948).

Changes for libheif:

• update to 1.23.5:

• (GHSA-v8qw-hwjv-44hw) Memory exhaustion through a mismatch between the container and the bitstream image size. A crafted image can declare a small size in its ispe property while the bitstream declares a much larger coded frame. The container-level checks used the ispe size, so the oversized bitstream reached the decoder, which allocated a frame buffer for the in-band size before libheif rejected the mismatch. The advisory demonstrated this for AV1 with the libaom backend (a 351-byte AVIF declaring 64x64 but coding up to 27648x27648, allocating hundreds of MB to more than 10 GB), but the same class affects every codec whose real frame size lives in the bitstream. The coded size is now checked against max_image_size_pixels in the codec- independent decode path, before any bytes reach a decoder plugin: all AV1 sequence headers, all HEVC/AVC/VVC SPS NAL units (including those carried in the item data, not only the ones in the configuration record), the JPEG SOF marker and the JPEG 2000 SIZ reference grid are scanned for the largest coded size. (high)
• (GHSA-qwpf-5wf7-r996) Heap use-after-free and double free when encoding an image that carries a TAI timestamp, including transcoding a file with an itai property. ImageDescription shallow-copied its raw heif_tai_timestamp_packet pointer, and a temporary in ImageItem::encode_to_bitstream_and_boxes() freed the packet while the item and the source image still held it. The timestamp is now stored by value. (medium)
• (GHSA-9c75-9g8r-4728) Memory amplification through a JPEG 2000 pclr box declaring zero palette columns. The entry-count bound was skipped for zero columns, so an 11-byte box allocated 65,535 empty palette entries, and nested j2kH containers could repeat this within the child and nesting limits: a 3 KB file reached about 330 MB RSS, none of it charged to max_total_memory. Zero columns are rejected (ISO/IEC 15444-1 requires 1 to 255), the byte bound is unconditional, and the palette storage is charged to the memory limits. (medium)
• (GHSA-r7gr-2xm2-23wf) Heap out-of-bounds read in alpha compositing for uncompressed (unci) images whose colour planes have different bit depths. Op_flatten_alpha_plane read every plane through the sample type of the first colour plane, so an 8-bit blue plane next to 16-bit red and green planes was read with a halved stride past its end, and the bytes ended up in the composited output. ColorState now tracks one bit depth per plane, and the operator declines mixed sample widths at planning time. (medium)
• (GHSA-q492-cfcm-895h) The OpenJPEG decoder plugin's pre-decode size check bounded the JPEG 2000 window span (x1-x0)*(y1-y0) but not the absolute reference-grid coordinates, so a codestream with a 17-pixel window on a grid near the 32-bit boundary reached opj_decode(). Against OpenJPEG 2.3.1 this produced a heap-buffer-overflow write inside OpenJPEG (the class of CVE-2020-6851); OpenJPEG 2.5.4 rejects the input. The reference-grid area is now bounded as well. (low)
• (GHSA-qfj5-c4pq-q998) Heap out-of-bounds read in the uncompressed encoder when an…

This update for libheif fixes the following issues:

• AV1/libaom path allows allocation before libheif rejects mismatched coded dimensions (bsc#1281953).
• Caller-configured security limits not enforced for MINI-box parsing (bsc#1281952).
• Heap out-of-bounds read in libheif alpha compositing via mismatched per-channel bit depths (bsc#1281951).
• Heap-use-after-free and double free in ImageItem::encode_to_bitstream_and_boxes (bsc#1281949).
• Incomplete OpenJPEG pre-decode security limits allow unsafe decode through the public API (bsc#1281954).
• JPEG 2000 pclr zero-column allocation amplification bypasses max_total_memory (bsc#1281950).
• Out-of-bounds heap read in unc_encoder_rgb_pixel_interleave (bsc#1281948).

Changes for libheif:

Update to 1.23.5:

• (GHSA-v8qw-hwjv-44hw) Memory exhaustion through a mismatch between the container and the bitstream image size. A crafted image can declare a small size in its ispe property while the bitstream declares a much larger coded frame. The container-level checks used the ispe size, so the oversized bitstream reached the decoder, which allocated a frame buffer for the in-band size before libheif rejected the mismatch. The advisory demonstrated this for AV1 with the libaom backend (a 351-byte AVIF declaring 64x64 but coding up to 27648x27648, allocating hundreds of MB to more than 10 GB), but the same class affects every codec whose real frame size lives in the bitstream. The coded size is now checked against max_image_size_pixels in the codec- independent decode path, before any bytes reach a decoder plugin: all AV1 sequence headers, all HEVC/AVC/VVC SPS NAL units (including those carried in the item data, not only the ones in the configuration record), the JPEG SOF marker and the JPEG 2000 SIZ reference grid are scanned for the largest coded size. (high)
• (GHSA-qwpf-5wf7-r996) Heap use-after-free and double free when encoding an image that carries a TAI timestamp, including transcoding a file with an itai property. ImageDescription shallow-copied its raw heif_tai_timestamp_packet pointer, and a temporary in ImageItem::encode_to_bitstream_and_boxes() freed the packet while the item and the source image still held it. The timestamp is now stored by value. (medium)
• (GHSA-9c75-9g8r-4728) Memory amplification through a JPEG 2000 pclr box declaring zero palette columns. The entry-count bound was skipped for zero columns, so an 11-byte box allocated 65,535 empty palette entries, and nested j2kH containers could repeat this within the child and nesting limits: a 3 KB file reached about 330 MB RSS, none of it charged to max_total_memory. Zero columns are rejected (ISO/IEC 15444-1 requires 1 to 255), the byte bound is unconditional, and the palette storage is charged to the memory limits. (medium)
• (GHSA-r7gr-2xm2-23wf) Heap out-of-bounds read in alpha compositing for uncompressed (unci) images whose colour planes have different bit depths. Op_flatten_alpha_plane read every plane through the sample type of the first colour plane, so an 8-bit blue plane next to 16-bit red and green planes was read with a halved stride past its end, and the bytes ended up in the composited output. ColorState now tracks one bit depth per plane, and the operator declines mixed sample widths at planning time. (medium)
• (GHSA-q492-cfcm-895h) The OpenJPEG decoder plugin's pre-decode size check bounded the JPEG 2000 window span (x1-x0)*(y1-y0) but not the absolute reference-grid coordinates, so a codestream with a 17-pixel window on a grid near the 32-bit boundary reached opj_decode(). Against OpenJPEG 2.3.1 this produced a heap-buffer-overflow write inside OpenJPEG (the class of CVE-2020-6851); OpenJPEG 2.5.4 rejects the input. The reference-grid area is now bounded as well. (low)
• (GHSA-qfj5-c4pq-q998) Heap out-of-bounds read in the uncompressed encoder when an application attached a separate alpha plane to an image with an interleaved chroma…

It was discovered that OpenJPEG incorrectly handled certain image files. A remote attacker could possibly use this issue to cause a denial of service. (CVE-2016-9112)

It was discovered that OpenJPEG did not properly handle certain input. If OpenJPEG were supplied with specially crafted input, it could be made to crash or potentially execute arbitrary code. (CVE-2018-20847, CVE-2018-21010, CVE-2020-6851, CVE-2020-8112, CVE-2020-15389)

It was discovered that OpenJPEG incorrectly handled certain BMP files. A remote attacker could possibly use this issue to cause a denial of service. (CVE-2019-12973)

It was discovered that Ghostscript incorrectly handled certain image files. If a user or automated system were tricked into processing a specially crafted file, a remote attacker could use this issue to cause Ghostscript to crash, resulting in a denial of service, or possibly execute arbitrary code.

Sebastian Poeplau discovered that OpenJPEG incorrectly handled certain inputs. If a user or an automated system were tricked into opening a specially crafted input file, a remote attacker could possibly use this issue to cause a denial of service or execute arbitrary code. This issue only affected Ubuntu 18.04 LTS. (CVE-2020-6851, CVE-2020-8112)

It was discovered that OpenJPEG incorrectly handled certain inputs. If a user or an automated system were tricked into opening a specially crafted input file, a remote attacker could possibly use this issue to cause a denial of service or execute arbitrary code. This issue only affected Ubuntu 18.04 LTS. (CVE-2020-15389, CVE-2020-27814, CVE-2020-27823, CVE-2020-27824, CVE-2020-27841, CVE-2020-27845)

It was discovered that OpenJPEG incorrectly handled certain inputs. If a user or an automated system were tricked into opening a specially crafted input file, a remote attacker could possibly use this issue to cause a denial of service. (CVE-2020-27842, CVE-2020-27843)