Pillow JPEG2000 tiled decode retains a growing scratch buffer and can be used for denial of service

Open Source Vulnerabilities GHSA-vjc4-5qp5-m44j

### Summary `src/libImaging/Jpeg2KDecode.c:853` accumulates `total_component_width` across every tile in a JPEG2000 image instead of recomputing it per tile. That accumulated value is then used in the `tile_bytes` calculation at `src/libImaging/Jpeg2KDecode.c:868`, which can make the decoder grow `state->buffer` via `realloc` at `src/libImaging/Jpeg2KDecode.c:876` up to roughly one full image's decompressed size even when each tile is small. A crafted tiled JPEG2000 file can therefore force substantially higher transient memory usage and trigger out-of-memory failures during decoding. Based on current evidence, the supported impact is denial of service, not memory corruption. ### Details - Location: `src/libImaging/Jpeg2KDecode.c:853` - Root cause: `total_component_width` is initialized only once before the tile loop and keeps growing across tiles. It is then used to derive `tile_bytes`, so later tiles are treated as if they had the combined component width of all earlier tiles. - Dangerous operation: `tile_bytes` is promoted into `tile_info.data_size`, then `state->buffer` is grown with `realloc` at `src/libImaging/Jpeg2KDecode.c:876`. - Reachability: any attacker-controlled JPEG2000 image with many tiles reaches this path during normal `Image.open(...).load()` decoding. ### PoC The attached helper script and testcase were used: [exercise_j2k_tile_realloc.zip](https://github.com/user-attachments/files/28099912/exercise_j2k_tile_realloc.zip) Generate the testcase: ```bash pythonexercise_j2k_tile_realloc.py make poc_3664_rgba_tile1832.jp2 \ --size 3664 --tile 1832 ``` Expected geometry from the helper: - image size: `3664 x 3664` - mode: `RGBA` - tile size: `1832 x 1832` (`2x2` tiles) - `image_bytes=53699584` - uncapped RSS observed: - vulnerable build: `maxrss_kb=180264` - fixed comparison build: `maxrss_kb=138404` Load it with the current vulnerable build: ```bash python exercise_j2k_tile_realloc.py load poc_3664_rgba_tile1832.jp2 ``` Load it again under a 160 MB address-space cap: ```bash python exercise_j2k_tile_realloc.py load poc_3664_rgba_tile1832.jp2 --limit-mb 160 ``` ### Impact Conservative impact: denial of service through memory exhaustion during JPEG2000 decoding.

Open Source Vulnerabilities BIT-pillow-2026-59204

Pillow is a Python imaging library. From 8.2.0 through 12.2.0, src/libImaging/Jpeg2KDecode.c accumulates total_component_width across every tile in a JPEG2000 image instead of recomputing it per tile, allowing a crafted tiled JPEG2000 file to force substantially higher transient memory usage and trigger out-of-memory failures during decoding. This issue is fixed in version 12.3.0.

Open Source Vulnerabilities CVE-2026-59204

Pillow is a Python imaging library. From 8.2.0 through 12.2.0, src/libImaging/Jpeg2KDecode.c accumulates total_component_width across every tile in a JPEG2000 image instead of recomputing it per tile, allowing a crafted tiled JPEG2000 file to force substantially higher transient memory usage and trigger out-of-memory failures during decoding. This issue is fixed in version 12.3.0.

Open Source Vulnerabilities PYSEC-2026-3496

### Summary `src/libImaging/Jpeg2KDecode.c:853` accumulates `total_component_width` across every tile in a JPEG2000 image instead of recomputing it per tile. That accumulated value is then used in the `tile_bytes` calculation at `src/libImaging/Jpeg2KDecode.c:868`, which can make the decoder grow `state->buffer` via `realloc` at `src/libImaging/Jpeg2KDecode.c:876` up to roughly one full image's decompressed size even when each tile is small. A crafted tiled JPEG2000 file can therefore force substantially higher transient memory usage and trigger out-of-memory failures during decoding. Based on current evidence, the supported impact is denial of service, not memory corruption. ### Details - Location: `src/libImaging/Jpeg2KDecode.c:853` - Root cause: `total_component_width` is initialized only once before the tile loop and keeps growing across tiles. It is then used to derive `tile_bytes`, so later tiles are treated as if they had the combined component width of all earlier tiles. - Dangerous operation: `tile_bytes` is promoted into `tile_info.data_size`, then `state->buffer` is grown with `realloc` at `src/libImaging/Jpeg2KDecode.c:876`. - Reachability: any attacker-controlled JPEG2000 image with many tiles reaches this path during normal `Image.open(...).load()` decoding. ### PoC The attached helper script and testcase were used: [exercise_j2k_tile_realloc.zip](https://github.com/user-attachments/files/28099912/exercise_j2k_tile_realloc.zip) Generate the testcase: ```bash pythonexercise_j2k_tile_realloc.py make poc_3664_rgba_tile1832.jp2 \ --size 3664 --tile 1832 ``` Expected geometry from the helper: - image size: `3664 x 3664` - mode: `RGBA` - tile size: `1832 x 1832` (`2x2` tiles) - `image_bytes=53699584` - uncapped RSS observed: - vulnerable build: `maxrss_kb=180264` - fixed comparison build: `maxrss_kb=138404` Load it with the current vulnerable build: ```bash python exercise_j2k_tile_realloc.py load poc_3664_rgba_tile1832.jp2 ``` Load it again under a 160 MB address-space cap: ```bash python exercise_j2k_tile_realloc.py load poc_3664_rgba_tile1832.jp2 --limit-mb 160 ``` ### Impact Conservative impact: denial of service through memory exhaustion during JPEG2000 decoding.