Summary

jpeg2000input.cpp:395 computes buffer size as const int bufsize = w * h * ch * buffer_bpp using signed 32-bit arithmetic. When the product exceeds INT_MAX, the result wraps to 0 or a small value. m_buf.resize() allocates an undersized buffer, and subsequent pixel write loops cause heap overflow. Conditional on USE_OPENJPH build flag.

Details

Line 395:

const int bufsize = w * h * ch * buffer_bpp;  // all int, signed overflow
m_buf.resize(bufsize);  // undersized or empty buffer

Lines 419-447 then write pixels based on actual w*h*ch dimensions into the undersized buffer.

For w=32768, h=32768, ch=4, buffer_bpp=2:

• True size: 8,589,934,592 bytes (8.0 GB)
• As signed int32: 0 (wraps)
• m_buf.resize(0) → empty buffer
• Pixel writes → massive heap overflow

Additionally, the JPEG2000 reader never calls check_open(), bypassing the global limit_imagesize_MB protection that guards other format readers.

This is the same pattern fixed in CVE-2023-42295 (BMP signed integer overflow).

PoC

Arithmetic proof:

#include <stdio.h>
#include <limits.h>

int main(void) {
    int w = 32768, h = 32768, ch = 4, bpp = 2;
    int bufsize = w * h * ch * bpp;
    long long real_size = (long long)w * h * ch * bpp;
    printf("int result:  %d\n", bufsize);    // 0
    printf("real result: %lld\n", real_size); // 8589934592
    printf("Overflow:    YES\n");
    return 0;
}

Output:

int result:  0
real result: 8589934592
Overflow:    YES

A valid HTJ2K codestream with large dimensions would trigger the heap overflow at runtime. Generating one requires an HTJ2K encoder.

Suggested fix

size_t bufsize = size_t(w) * size_t(h) * size_t(ch) * size_t(buffer_bpp);
if (bufsize > size_t(std::numeric_limits<int>::max())) {
    errorfmt("Image too large for buffer allocation");
    return false;
}
m_buf.resize(bufsize);

Also add check_open() call to enforce dimension limits consistently with other readers.

Impact

Heap buffer overflow when opening a crafted JPEG2000 file with large dimensions. Only affects builds compiled with USE_OPENJPH. Same vulnerability class as CVE-2023-42295 (BMP integer overflow, fixed in 2.5.3.0).