opj_decompress: fix off-by-one read heap-buffer-overflow in sycc420_to_rgb() when x0 and y0 are odd (CVE-2021-3575, fixes #1347)

[rouault]

Now Valgrind output is clean:

$ valgrind ./bin/opj_decompress -i ./poc.j2k -o out.png
==167167== Memcheck, a memory error detector
==167167== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==167167== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==167167== Command: ./bin/opj_decompress -i ./poc.j2k -o out.png
==167167== 

[INFO] Start to read j2k main header (0).
[ERROR] Unknown progression order in COD marker
[WARNING] Unknown marker
[ERROR] Unknown progression order in COD marker
[WARNING] Unknown marker
[WARNING] Unknown marker
[WARNING] Unknown marker
[ERROR] Unknown progression order in COD marker
[WARNING] Unknown marker
[WARNING] Unknown marker
[WARNING] Unknown marker
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[INFO] Psot value of the current tile-part is equal to zero, we assuming it is the last tile-part of the codestream.
[INFO] Header of tile 1 / 1 has been read.
[INFO] Tile 1/1 has been decoded.
[INFO] Image data has been updated with tile 1.

imagetopng: All components shall have the same subsampling, same bit depth, same sign.
	Aborting
[ERROR] Error generating png file. Outfile out.png not generated

Previously it reported:

==167517== Invalid read of size 4
==167517==    at 0x1308EC: sycc420_to_rgb (color.c:379)
==167517==    by 0x130B79: color_sycc_to_rgb (color.c:416)
==167517==    by 0x121624: main (opj_decompress.c:1629)
==167517==  Address 0x4d7ff80 is 0 bytes after a block of size 288 alloc'd
==167517==    at 0x483E0F0: memalign (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==167517==    by 0x483E212: posix_memalign (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==167517==    by 0x48C0EE8: opj_aligned_alloc_n (opj_malloc.c:61)
==167517==    by 0x48C1092: opj_aligned_malloc (opj_malloc.c:209)
==167517==    by 0x489042A: opj_image_data_alloc (openjpeg.c:1135)
==167517==    by 0x48BADF0: opj_alloc_tile_component_data (tcd.c:765)
==167517==    by 0x48BD265: opj_tcd_decode_tile (tcd.c:1629)
==167517==    by 0x487DA54: opj_j2k_decode_tile (j2k.c:9887)
==167517==    by 0x48825E1: opj_j2k_decode_tiles (j2k.c:11733)
==167517==    by 0x487BA3F: opj_j2k_exec (j2k.c:9031)
==167517==    by 0x48831C4: opj_j2k_decode (j2k.c:12036)
==167517==    by 0x488F6E8: opj_decode (openjpeg.c:526)
==167517== 

[deekal2]

Is there a plan to release v2.5.1 with the fix anytime soon?

[rouault]

Is there a plan to release v2.5.1 with the fix anytime soon?

yes, as indicated on the mailing list : https://groups.google.com/g/openjpeg/c/Mrz0Zeo79WY
"I'll hope to tackle soon a 2.5.1 release. Use that as a signal to test
master and report any regression, or if there are changes that need to
go in it, be sure to provide pull requests soon "