Hi,

The frame size check added in 3.0.24-11 by
CVE-2025-53618_CVE-2025-53619.patch (upstream f0e359c) rejects frames
that carry the one byte of padding DICOM adds to odd-length values. As a
result, JPEG encoding fails for images whose pixel data has an odd
length, for example a 3x3 RGB image (27 bytes, padded to 28).

To reproduce on sid with libgdcm-tools 3.0.24-14, using
SC_rgb_small_odd.dcm from the pydicom test data (3x3, RGB):

  $ gdcmconv --jpeg SC_rgb_small_odd.dcm out.dcm
  Could not change the Transfer Syntax: SC_rgb_small_odd.dcm
  $ echo $?
  1

SC_rgb_small_odd_big_endian.dcm fails the same way. With 3.0.24-5
(trixie) both files convert fine. I noticed it while testing the CVE
patches backported to trixie.

Upstream fixed it in 9ced0f9 ("Accepth odd length", released in
3.2.9):https://github.com/malaterre/GDCM/commit/9ced0f9ae1d6ecb9e84c2a06db36c9697815108f

The change is one line in gdcmJPEGBITSCodec.hxx:

-  if (len != expected_frame_size) {
+  if (len != expected_frame_size && len != expected_frame_size + 1) {

The attached patch has a DEP-3 header and goes in debian/patches/series
right after CVE-2025-53618_CVE-2025-53619.patch. In my trixie build
with it, both files convert again and the output is identical to
3.0.24-5.

I am preparing a trixie-pu update for the six gdcm CVEs and would like to
include this fix there too, so it would help to have it in unstable
first.

Thanks,
Valentín Torassa