[med-svn] [Git][med-team/dcmtk][debian/bookworm] 5 commits: d/changelog: unrelease to integrate new security patches.

Étienne Mollier (@emollier) gitlab at salsa.debian.org
Thu Feb 20 21:01:15 GMT 2025



Étienne Mollier pushed to branch debian/bookworm at Debian Med / dcmtk


Commits:
09bedcd6 by Étienne Mollier at 2025-02-20T21:50:52+01:00
d/changelog: unrelease to integrate new security patches.

- - - - -
9fed143c by Étienne Mollier at 2025-02-20T21:52:50+01:00
0009-CVE-2025-25475.patch: new: fix CVE-2025-25475.

Closes: #1098373

- - - - -
d932b1d1 by Étienne Mollier at 2025-02-20T21:56:23+01:00
0010-CVE-2025-25474.patch: new: fix CVE-2025-25474.

Closes: #1098374

- - - - -
c56ab1d5 by Étienne Mollier at 2025-02-20T21:58:30+01:00
0011-CVE-2025-25472.patch: new: fix CVE-2025-25472.

- - - - -
895d58de by Étienne Mollier at 2025-02-20T22:00:21+01:00
d/changelog: ready for bookworm proposed update.

- - - - -


5 changed files:

- debian/changelog
- + debian/patches/0009-CVE-2025-25475.patch
- + debian/patches/0010-CVE-2025-25474.patch
- + debian/patches/0011-CVE-2025-25472.patch
- debian/patches/series


Changes:

=====================================
debian/changelog
=====================================
@@ -13,8 +13,11 @@ dcmtk (3.6.7-9~deb12u3) bookworm; urgency=medium
     with the nuance that upstream check functions are inlined, in order to
     avoid an ABI breakage.
     Thanks to Adrian Bunk (Closes: #1070207)
+  * 0009-CVE-2025-25475.patch: new: fix CVE-2025-25475. (Closes: #1098373)
+  * 0010-CVE-2025-25474.patch: new: fix CVE-2025-25474. (Closes: #1098374)
+  * 0011-CVE-2025-25472.patch: new: fix CVE-2025-25472.
 
- -- Étienne Mollier <emollier at debian.org>  Thu, 13 Feb 2025 17:48:57 +0100
+ -- Étienne Mollier <emollier at debian.org>  Thu, 20 Feb 2025 21:59:03 +0100
 
 dcmtk (3.6.7-9~deb12u2) bookworm; urgency=medium
 


=====================================
debian/patches/0009-CVE-2025-25475.patch
=====================================
@@ -0,0 +1,27 @@
+commit bffa3e9116abb7038b432443f16b1bd390e80245
+Author: Marco Eichelberg <eichelberg at offis.de>
+Date:   Thu Jan 23 15:51:21 2025 +0100
+
+    Fixed issue with invalid RLE compressed DICOM images.
+    
+    Fixed issue when processing an RLE compressed image where the RLE header
+    contains an invalid stripe size.
+    
+    Thanks to Ding zhengzheng <xiaozheng.ding399 at gmail.com> for the report
+    and the sample file (PoC).
+
+--- dcmtk.orig/dcmdata/libsrc/dcrleccd.cc
++++ dcmtk/dcmdata/libsrc/dcrleccd.cc
+@@ -330,6 +330,12 @@
+                     } /* while */
+ 
+                     // last fragment for this RLE stripe
++                    if (inputBytes + byteOffset > fragmentLength)
++                    {
++                        DCMDATA_ERROR("stream size in RLE header is wrong");
++                        inputBytes = fragmentLength-byteOffset;
++                    }
++
+                     result = rledecoder.decompress(rleData + byteOffset, OFstatic_cast(size_t, inputBytes));
+ 
+                     // special handling for zero pad byte at the end of the RLE stream


=====================================
debian/patches/0010-CVE-2025-25474.patch
=====================================
@@ -0,0 +1,34 @@
+commit 1d205bcd307164c99e0d4bbf412110372658d847
+Author: Joerg Riesmeier <dicom at jriesmeier.com>
+Date:   Tue Jan 21 11:12:28 2025 +0100
+
+    Fixed another issue with invalid DICOM images.
+    
+    Fixed issue when processing an invalid DICOM image where the number of
+    pixels stored does not match the expected number of pixels (too less)
+    and the combination of BitsAllocated and BitsStored is really unusual
+    (e.g. 1 bit stored, but 52 bits allocated). In cases where the last
+    pixel (e.g. a single bit) does not fit into the buffer of the input
+    pixel data, a buffer overflow occurred on the heap. Now, the last entry
+    of the buffer is filled with the smallest possible value (e.g. 0 in case
+    of unsigned data).
+    
+    Thanks to Ding zhengzheng <xiaozheng.ding399 at gmail.com> for the report
+    and the sample file (PoC).
+
+--- dcmtk.orig/dcmimgle/include/dcmtk/dcmimgle/diinpxt.h
++++ dcmtk/dcmimgle/include/dcmtk/dcmimgle/diinpxt.h
+@@ -643,6 +643,13 @@
+                             skip -= times * bitsof_T1;
+                         }
+                     }
++                    /* fill the remaining entry (if any) with the smallest value that is possible */
++                    if (q < Data + Count)
++                    {
++                        DCMIMGLE_TRACE("not enough data, filling last entry of input buffer with value = " << getAbsMinimum());
++                        *q = OFstatic_cast(T2, getAbsMinimum());
++                    }
++
+                 }
+             } else
+                 DCMIMGLE_DEBUG("cannot allocate memory buffer for 'Data' in DiInputPixelTemplate::convert()");


=====================================
debian/patches/0011-CVE-2025-25472.patch
=====================================
@@ -0,0 +1,49 @@
+commit 410ffe2019b9db6a8f4036daac742a6f5e4d36c2
+Author: Joerg Riesmeier <dicom at jriesmeier.com>
+Date:   Fri Jan 17 17:53:50 2025 +0100
+
+    Fixed another issue with invalid mono images.
+    
+    Fixed issue when rendering an invalid monochrome DICOM image where the
+    number of pixels stored does not match the expected number of pixels.
+    In this case, only a single pixel is processed, but the pixel matrix is
+    much larger. Filling the rest of the pixel matrix with the smallest
+    possible value for the image is not working because of an optimized
+    memory usage (value would be out of range). Now, the pixel value to be
+    used is double-checked before it is actually filled into the "background"
+    of the image.
+    
+    Thanks to Ding zhengzheng <xiaozheng.ding399 at gmail.com> for the report
+    and the sample file (PoC).
+
+diff --git a/dcmimgle/include/dcmtk/dcmimgle/dimoipxt.h b/dcmimgle/include/dcmtk/dcmimgle/dimoipxt.h
+index 50389a540..f67967310 100644
+--- a/dcmimgle/include/dcmtk/dcmimgle/dimoipxt.h
++++ b/dcmimgle/include/dcmtk/dcmimgle/dimoipxt.h
+@@ -28,6 +28,7 @@
+ #include "dcmtk/ofstd/ofbmanip.h"
+ #include "dcmtk/ofstd/ofcast.h"
+ #include "dcmtk/ofstd/ofdiag.h"      /* for DCMTK_DIAGNOSTIC macros */
++#include "dcmtk/ofstd/oflimits.h"    /* for OFnumeric_limits<> */
+ 
+ #include "dcmtk/dcmimgle/dimopxt.h"
+ #include "dcmtk/dcmimgle/diinpx.h"
+@@ -72,9 +73,16 @@ class DiMonoInputPixelTemplate
+                 rescale(pixel);                     // "copy" or reference pixel data
+                 this->determineMinMax(OFstatic_cast(T3, this->Modality->getMinValue()), OFstatic_cast(T3, this->Modality->getMaxValue()));
+             }
+-            /* erase empty part of the buffer (= fill the background with the smallest possible value) */
++            /* erase empty part of the buffer */
+             if ((this->Data != NULL) && (this->InputCount < this->Count))
+-                OFBitmanipTemplate<T3>::setMem(this->Data + this->InputCount, OFstatic_cast(T3, this->Modality->getAbsMinimum()), this->Count - this->InputCount);
++            {
++                /* that means, fill the background with the smallest value that is possible */
++                const T3 minOut = OFnumeric_limits<T3>::min();
++                const T3 background = (this->Modality->getAbsMinimum() < OFstatic_cast(double, minOut)) ? minOut : OFstatic_cast(T3, this->Modality->getAbsMinimum());
++                const size_t count = (this->Count - this->InputCount);
++                DCMIMGLE_DEBUG("filing empty part of the intermediate pixel data (" << count << " pixels) with value = " << OFstatic_cast(double, background));
++                OFBitmanipTemplate<T3>::setMem(this->Data + this->InputCount, background, count);
++            }
+         }
+     }
+ 


=====================================
debian/patches/series
=====================================
@@ -18,3 +18,6 @@ c34f4e46e672ad21accf04da0dc085e43be6f5e1.patch
 0001-Fixed-unchecked-typecasts-of-DcmItem-search-results.patch
 0002-Fixed-unchecked-typecasts-and-fixed-LUT-handling.patch
 0003-Fixed-wrong-error-handling-previous-commit.patch
+0009-CVE-2025-25475.patch
+0010-CVE-2025-25474.patch
+0011-CVE-2025-25472.patch



View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/compare/9197baff3767c4a91ff16e30dafdcf09d7001ceb...895d58dedeed1d92ea5221ee6129e9479d6efb18

-- 
View it on GitLab: https://salsa.debian.org/med-team/dcmtk/-/compare/9197baff3767c4a91ff16e30dafdcf09d7001ceb...895d58dedeed1d92ea5221ee6129e9479d6efb18
You're receiving this email because of your account on salsa.debian.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-commit/attachments/20250220/c8ac7152/attachment-0001.htm>


More information about the debian-med-commit mailing list