From 3e18236b69f0336bd255791032ab19651f5476ff Mon Sep 17 00:00:00 2001 From: Funda Wang Date: Tue, 1 Apr 2025 13:23:51 +0800 Subject: [PATCH] Fix CVE-2025-27831 (cherry picked from commit b9796d31149f92dae08eccc32a0f4abdd92039bc) --- backport-CVE-2025-27831.patch | 121 ++++++++++++++++++++++++++++++++++ ghostscript.spec | 17 +++-- 2 files changed, 133 insertions(+), 5 deletions(-) create mode 100644 backport-CVE-2025-27831.patch diff --git a/backport-CVE-2025-27831.patch b/backport-CVE-2025-27831.patch new file mode 100644 index 0000000..7a80623 --- /dev/null +++ b/backport-CVE-2025-27831.patch @@ -0,0 +1,121 @@ +Partial backport of: + +From bf79b61cb1677d6865c45d397435848a21e8a647 Mon Sep 17 00:00:00 2001 +From: Ken Sharp +Date: Tue, 27 Sep 2022 13:03:57 +0100 +Subject: [PATCH] PCL interpreter - fix decode_glyph for Unicode + +The text extraction (and pdfwrite family) expect that decode_glyph +should always return pairs of bytes (an assumption that Unicode code +points are 2 bytes), and the return value from the routine should be +the number of bytes required to hold the value. + +The PCL decode_glyph routine however was simply returning 1, which +caused the text extraction code some difficulty since it wasn't +expecting that. + +This commit firstly alters the text extraction code to cope 'better' +with a decode_glyph routine which returns an odd value (basically +ignore it and fall back to using the character code). + +We also alter the pl_decode_glyph routine to return 2 instead of 1, +so that it correctly tells the caller that it is returning 2 bytes. +Finally we make sure that the returned value is big-endian, because the +text extraction code assumes it will be. +--- + devices/vector/doc_common.c | 8 ++++++++ + pcl/pl/plfont.c | 12 +++++++++--- + 2 files changed, 17 insertions(+), 3 deletions(-) + +--- a/devices/vector/doc_common.c ++++ b/devices/vector/doc_common.c +@@ -513,6 +513,14 @@ int txt_get_unicode(gx_device *dev, gs_f + char *b, *u; + int l = length - 1; + ++ /* Real Unicode values should be at least 2 bytes. In fact I think the code assumes exactly ++ * 2 bytes. If we got an odd number, give up and return the character code. ++ */ ++ if (length & 1) { ++ *Buffer = fallback; ++ return 1; ++ } ++ + unicode = (ushort *)gs_alloc_bytes(dev->memory, length, "temporary Unicode array"); + length = font->procs.decode_glyph((gs_font *)font, glyph, ch, unicode, length); + #if ARCH_IS_BIG_ENDIAN +From d6e713dda4f8d75c6a4ed8c7568a0d4f532dcb17 Mon Sep 17 00:00:00 2001 +From: Zdenek Hutyra +Date: Thu, 21 Nov 2024 10:04:17 +0000 +Subject: Prevent Unicode decoding overrun + +Bug #708132 "Text buffer overflow with long characters" + +The txt_get_unicode function was copying too few bytes from the +fixed glyph name to unicode mapping tables. This was probably +causing incorrect Unicode code points in relatively rare cases but +not otherwise a problem. + +However, a badly formed GlyphNames2Unicode array attached to a font +could cause the decoding to spill over the assigned buffer. + +We really should rewrite the Unicode handling, but until we do just +checking that the length is no more than 4 Unicode code points is +enough to prevent an overrun. All the current clients allocate at least +4 code points per character code. + +Added a comment to explain the magic number. + +CVE-2025-27831 +--- + devices/vector/doc_common.c | 14 +++++++++----- + 1 file changed, 9 insertions(+), 5 deletions(-) + +--- a/devices/vector/doc_common.c ++++ b/devices/vector/doc_common.c +@@ -463,7 +463,7 @@ int txt_get_unicode(gx_device *dev, gs_f + } + if (strlen(dentry->Glyph) == gnstr.size) { + if(memcmp(gnstr.data, dentry->Glyph, gnstr.size) == 0) { +- memcpy(Buffer, dentry->Unicode, 2); ++ memcpy(Buffer, dentry->Unicode, 2 * sizeof(unsigned short)); + return 2; + } + } +@@ -481,7 +481,7 @@ int txt_get_unicode(gx_device *dev, gs_f + } + if (strlen(tentry->Glyph) == gnstr.size) { + if(memcmp(gnstr.data, tentry->Glyph, gnstr.size) == 0) { +- memcpy(Buffer, tentry->Unicode, 3); ++ memcpy(Buffer, tentry->Unicode, 3 * sizeof(unsigned short)); + return 3; + } + } +@@ -499,7 +499,7 @@ int txt_get_unicode(gx_device *dev, gs_f + } + if (strlen(qentry->Glyph) == gnstr.size) { + if(memcmp(gnstr.data, qentry->Glyph, gnstr.size) == 0) { +- memcpy(Buffer, qentry->Unicode, 4); ++ memcpy(Buffer, qentry->Unicode, 4 * sizeof(unsigned short)); + return 4; + } + } +@@ -511,12 +511,16 @@ int txt_get_unicode(gx_device *dev, gs_f + return 1; + } else { + char *b, *u; +- int l = length - 1; ++ int l; + + /* Real Unicode values should be at least 2 bytes. In fact I think the code assumes exactly + * 2 bytes. If we got an odd number, give up and return the character code. ++ * ++ * The magic number here is due to the clients calling this code. Currently txtwrite and docxwrite ++ * allow up to 4 Unicode values per character/glyph, if the length would exceed that we can't ++ * write it. For now, again, fall back to the character code. + */ +- if (length & 1) { ++ if (length & 1 || length > 4 * sizeof(unsigned short)) { + *Buffer = fallback; + return 1; + } diff --git a/ghostscript.spec b/ghostscript.spec index 497f26d..f500c92 100644 --- a/ghostscript.spec +++ b/ghostscript.spec @@ -9,7 +9,7 @@ Name: ghostscript Version: 9.55.0 -Release: 19 +Release: 20 Summary: An interpreter for PostScript and PDF files License: AGPLv3+ URL: https://ghostscript.com/ @@ -49,10 +49,11 @@ Patch22: backport-CVE-2024-46955.patch Patch23: backport-CVE-2024-46951.patch Patch24: backport-CVE-2024-46952.patch Patch25: backport-CVE-2025-27830.patch -Patch26: backport-CVE-2025-27832.patch -Patch27: backport-CVE-2025-27834.patch -Patch28: backport-CVE-2025-27835.patch -Patch39: backport-CVE-2025-27836.patch +Patch26: backport-CVE-2025-27831.patch +Patch27: backport-CVE-2025-27832.patch +Patch28: backport-CVE-2025-27834.patch +Patch29: backport-CVE-2025-27835.patch +Patch30: backport-CVE-2025-27836.patch Patch40: Add-CJK-Chinese-font-mappings.patch BuildRequires: automake gcc @@ -214,6 +215,12 @@ install -m 0755 -d %{buildroot}%{_datadir}/%{name}/conf.d/ %{_bindir}/dvipdf %changelog +* Tue Apr 01 2025 Funda Wang - 9.55.0-20 +- Type:CVE +- ID:NA +- SUG:NA +- DECS: Fix CVE-2025-27831 + * Mon Mar 31 2025 hdliu - 9.55.0-19 - Add font mappings so that the PS interpreter can rasterize Chinese content using the two fonts STKaiti-Regular and STheiti-Regular. -- Gitee