Update to OpenJPEG 2.3.0.

There is a regression for 2325_-_JPX_image_with_padding_rejected.pdf.
Object 3 in that document is a JPX-encoded image. Its EOC marker is
preceded by two extra bytes of data, 0x80 0x80. This makes the file
broken according to the JPEG 2000 specification.

Acrobat Reader and the Kakadu JPX decoder accepts this file without
issues, so OpenJPEG 2.1.0 added code to fix this (bug 226, commit
005e75bdc). That fix detects exactly two bytes of 0x80 0x80, a rather
brittle fix. Adding more padding or changing the padding byte values
is not accepted. Adding more padding is acceptable to Acrobat Reader
and Kakadu. An unrelated fix for another problem has since broken
OpenJPEG's support for this broken image.

1 files changed, 13 insertions, 3 deletions

diff --git a/source/fitz/load-jpx.c b/source/fitz/load-jpx.c
index 49d7a811..da9ce087 100644
--- a/source/fitz/load-jpx.c
+++ b/source/fitz/load-jpx.c
@@ -575,7 +575,7 @@ void opj_free(void *ptr)
 	fz_free(ctx, ptr);
 }
 
-void * opj_aligned_malloc(size_t size)
+static void * opj_aligned_malloc_n(size_t alignment, size_t size)
 {
 	uint8_t *ptr;
 	int off;
@@ -583,15 +583,25 @@ void * opj_aligned_malloc(size_t size)
 	if (size == 0)
 		return NULL;
 
-	size += 16 + sizeof(uint8_t);
+	size += alignment + sizeof(uint8_t);
 	ptr = opj_malloc(size);
 	if (ptr == NULL)
 		return NULL;
-	off = 16-(((int)(intptr_t)ptr) & 15);
+	off = alignment-(((int)(intptr_t)ptr) & (alignment - 1));
 	ptr[off-1] = off;
 	return ptr + off;
 }
 
+void * opj_aligned_malloc(size_t size)
+{
+	return opj_aligned_malloc_n(16, size);
+}
+
+void * opj_aligned_32_malloc(size_t size)
+{
+	return opj_aligned_malloc_n(32, size);
+}
+
 void opj_aligned_free(void* ptr_)
 {
 	uint8_t *ptr = (uint8_t *)ptr_;