Hi,

opj_j2k_read_sod() in src/lib/openjp2/j2k.c writes the end-of-header and
end-of-tile-part stream offsets into

cstr_index->tile_index[tileno].tp_index[current_tpsno]

without first checking that the tp_index array was allocated, or that
current_tpsno is within its allocated size (nb_tps). A crafted JPEG 2000
codestream that drives current_tpsno past the allocated tile-part index, or
that leaves tp_index NULL, causes a heap-buffer-overflow write during
decoding. The path is reached from opj_decode() through
opj_j2k_read_tile_header(), so decoding an untrusted .j2k/.jp2 file is
enough to trigger it; no special API use is required.

This was found by OSS-Fuzz (OSV-2025-219, heap-buffer-overflow WRITE in
opj_j2k_read_tile_header). I could not find a CVE assigned for it, nor an
existing bug in the BTS.

Upstream fixed it in pull request 1621, merged as commit d33cbec on main,
but no release has been cut that includes the fix, so all current Debian
versions are still affected:

sid/forky 2.5.4-1.1
trixie 2.5.3-2.1~deb13u2
bookworm 2.5.0-2+deb12u3

The vulnerable code is identical in all three, so the attached DEP-3 patch
applies cleanly to each. It is a straight backport of the upstream guard:
write the offsets only when tp_index is non-NULL and current_tpsno < nb_tps.
I confirmed it applies to the 2.5.4, 2.5.3 and 2.5.0 sources; the change is
a
bounds check only and does not affect decoding of valid files. I did not
rebuild each package separately.

Regards,
Sumit