Debian Patches
Status for ghostscript/10.0.0~dfsg-11+deb12u6
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001_fix_cross_compile.patch | [PATCH] Fix a little bitrot in the cross-compiling logic Removing the option to disable FAPI meant configuring for cross compiling would fail because the option being passed to the sub-call to configure would include an unknown command line option. |
Chris Liddell <chris.liddell@artifex.com> | no | debian | upstream, https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=4c3575346b9c7d394ebc73b4e5fabebadd8877ec | 2022-11-24 |
| 0002_Graphics-library-prevent-buffer-overrun-in-T-BCP-enc.patch | Graphics library - prevent buffer overrun in (T)BCP encoding Bug #706494 "Buffer Overflow in s_xBCPE_process" As described in detail in the bug report, if the write buffer is filled to one byte less than full, and we then try to write an escaped character, we overrun the buffer because we don't check before writing two bytes to it. This just checks if we have two bytes before starting to write an escaped character and exits if we don't (replacing the consumed byte of the input). Up for further discussion; why do we even permit a BCP encoding filter anyway ? I think we should remove this, at least when SAFER is true. |
Ken Sharp <ken.sharp@artifex.com> | yes | debian upstream | https://git.ghostscript.com/?p=ghostpdl.git;h=37ed5022cecd584de868933b5b60da2e995b3179 | 2023-03-24 |
| 0003_Bug-706761-Don-t-reduce-pipe-file-names-for-permissi.patch | Bug 706761: Don't "reduce" %pipe% file names for permission validation For regular file names, we try to simplfy relative paths before we use them. Because the %pipe% device can, effectively, accept command line calls, we shouldn't be simplifying that string, because the command line syntax can end up confusing the path simplifying code. That can result in permitting a pipe command which does not match what was originally permitted. Special case "%pipe" in the validation code so we always deal with the entire string. |
Chris Liddell <chris.liddell@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=5e65eeae225c7d02d447de5abaf4a8e6d234fcea | 2023-06-07 |
| 0004_Bug-706778-706761-revisit.patch | Bug 706778: 706761 revisit Two problems with the original commit. The first a silly typo inverting the logic of a test. The second was forgetting that we actually actually validate two candidate strings for pipe devices. One with the expected "%pipe%" prefix, the other using the pipe character prefix: "|". This addresses both those. |
Chris Liddell <chris.liddell@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=fb342fdb60391073a69147cb71af1ac416a81099 | 2023-06-14 |
| 0005-Bug-706897-Copy-pcx-buffer-overrun-fix-from-devices-.patch | Bug 706897: Copy pcx buffer overrun fix from devices/gdevpcx.c Bounds check the buffer, before dereferencing the pointer. |
Chris Liddell <chris.liddell@artifex.com> | no | debian | https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d81b82c70bc1fb9991bb95f1201abb5dea55f57f | 2023-07-17 |
| 0006-IJS-device-try-and-secure-the-IJS-server-startup.patch | IJS device - try and secure the IJS server startup Bug #707051 ""ijs" device can execute arbitrary commands" The problem is that the 'IJS' device needs to start the IJS server, and that is indeed an arbitrary command line. There is (apparently) no way to validate it. Indeed, this is covered quite clearly in the comments at the start of the source: * WARNING: The ijs server can be selected on the gs command line * which is a security risk, since any program can be run. Previously this used the awful LockSafetyParams hackery, which we abandoned some time ago because it simply couldn't be made secure (it was implemented in PostScript and was therefore vulnerable to PostScript programs). This commit prevents PostScript programs switching to the IJS device after SAFER has been activated, and prevents changes to the IjsServer parameter after SAFER has been activated. SAFER is activated, unless explicitly disabled, before any user PostScript is executed which means that the device and the server invocation can only be configured on the command line. This does at least provide minimal security against malicious PostScript programs. |
Ken Sharp <ken.sharp@artifex.com> | no | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=8b0f20002536867bd73ff4552408a72597190cbe | 2023-08-24 | |
| 0007-Bug-707264-Fix-tiffsep-1-requirement-for-seekable-ou.patch | Bug 707264: Fix tiffsep(1) requirement for seekable output files In the device initialization redesign, tiffsep and tiffsep1 lost the requirement for the output files to be seekable. Fixing that highlighted a problem with the error handling in gdev_prn_open_printer_seekable() where closing the erroring file would leave a dangling pointer, and lead to a crash. |
Chris Liddell <chris.liddell@artifex.com> | no | https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=5d2da96e81c7455338302c71a291088a8396245a | 2023-10-16 | |
| 0008-In-SAFER-default-don-t-allow-eexec-seeds-other-than-.patch | In SAFER (default) don't allow eexec seeds other than the Type 1 standard | Chris Liddell <chris.liddell@artifex.com> | no | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=1ff9a695947967d2d327c45bf5145dd381fc1745 | 2023-09-12 | |
| 0009-Uniprint-device-prevent-string-configuration-changes.patch | Uniprint device - prevent string configuration changes when SAFER Bug #707662 We cannot sanitise the string arguments used by the Uniprint device because they can potentially include anything. This commit ensures that these strings are locked and cannot be changed by PostScript once SAFER is activated. Full configuration from the command line is still possible (see the *.upp files in lib). This addresses CVE-2024-29510 |
Ken Sharp <Ken.Sharp@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=3b1735085ecef20b29e8db3416ab36de93e86d1f | 2024-03-21 |
| 0010-Bug-707691.patch | Bug #707691 Part 1; when stripping a potential Current Working Dirctory specifier from a path, make certain it really is a CWD, and not simply large ebough to be a CWD. Reasons are in the bug thread, this is not (IMO) serious. This is part of the fix for CVE-2024-33869 |
Ken Sharp <Ken.Sharp@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=5ae2e320d69a7d0973011796bd388cd5befa1a43 | 2024-03-26 |
| 0011-Bug-707691-part-2.patch | Bug 707691 part 2 See bug thread for details This is the second part of the fix for CVE-2024-33869 |
Ken Sharp <Ken.Sharp@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=f5336e5b4154f515ac83bc5b9eba94302e6618d4 | 2024-03-26 |
| 0012-Bug-707686.patch | Bug #707686 See bug thread for details In addition to the noted bug; an error path (return from gp_file_name_reduce not successful) could elad to a memory leak as we did not free 'bufferfull'. Fix that too. This addresses CVE-2024-33870 |
Ken Sharp <Ken.Sharp@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=79aef19c685984dc3da2dc090450407d9fbcff80 | 2024-03-26 |
| 0013-OPVP-device-prevent-unsafe-parameter-change-with-SAF.patch | OPVP device - prevent unsafe parameter change with SAFER Bug #707754 "OPVP device - Arbitrary code execution via custom Driver library" The "Driver" parameter for the "opvp"/"oprp" device specifies the name of a dynamic library and allows any library to be loaded. The patch does not allow changing this parameter after activating path control. This addresses CVE-2024-33871 |
Zdenek Hutyra <zhutyra@centrum.cz> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=7145885041bb52cc23964f0aa2aec1b1c82b5908 | 2024-04-22 |
| 0014-Bug-707510-review-printing-of-pointers.patch | Bug 707510 - review printing of pointers This is for item 4 of the report, which is addressed by the change in gdevpdtb.c. That change uses a fixed name for fonts which have no name instead of using the pointer to the address of the font. The remaining changes are all due to reviewing the use of PRI_INTPTR. In general we only use that for debugging purposes but there were a few places which were printing pointers arbitrarily, even in a release build. We really don't want to do that so I've modified the places which were printing pointer unconditionally so that they only do so if DEBUG is set at compile time, or a specific debug flag is set. |
Ken Sharp <Ken.Sharp@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ff1013a0ab485b66783b70145e342a82c670906a | 2024-01-25 |
| 0015-Fix-compiler-warning-in-optimised-build.patch | Fix compiler warning in optimised build We were declaring a local memory pointer only used in a debug build, use the pointer from the structure directly instead. |
Chris Liddell <chris.liddell@artifex.com> | no | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=147e5abd63d82c9ec3587c6f67a5d8ec7dc38e61 | 2024-02-14 | |
| 0016-Coverity-IDs-414141-414145.patch | Coverity IDs 414141 & 414145 These are the same problem reported two different ways. I forgot to remove the arguments to errprintf when I removed the format specifiers from the string as part of reviewing the pointer printing. |
Ken Sharp <Ken.Sharp@artifex.com> | no | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=d084021e06ba1caa1373fbbcf24a8510f43830ab | 2024-01-27 | |
| 0017-Bug-707510-don-t-allow-PDF-files-with-bad-Filters-to.patch | Bug 707510 - don't allow PDF files with bad Filters to overflow the debug buffer Item #2 of the report. Allocate a buffer to hold the filter name, instead of assuming it will fit in a fixed buffer. Reviewed all the other PDFDEBUG cases, no others use a fixed buffer like this. |
Ken Sharp <Ken.Sharp@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=77dc7f699beba606937b7ea23b50cf5974fa64b1 | 2024-01-25 |
| 0018-Bug-707510-don-t-use-strlen-on-passwords.patch | Bug 707510 - don't use strlen on passwords Item #1 of the report. This looks like an oversight when first coding the routine. We should use the PostScript string length, because PostScript strings may not be NULL terminated (and as here may contain internal NULL characters). Fix the R6 handler which has the same problem too. |
Ken Sharp <Ken.Sharp@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=917b3a71fb20748965254631199ad98210d6c2fb | 2024-01-25 |
| 0019-Bug-707510-3-Bounds-checks-when-using-CIDFont-relate.patch | Bug 707510(3): Bounds checks when using CIDFont related params Specifically, for CIDFont substitution. |
Chris Liddell <chris.liddell@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=7745dbe24514710b0cfba925e608e607dee9eb0f | 2024-01-24 |
| 0020-Bug-707793-Check-for-overflow-validating-format-stri.patch | Bug 707793: Check for overflow validating format string for the output file name CVE-2024-46953 |
Zdenek Hutyra <zhutyra@centrum.cz> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=294a3755e33f453dd92e2a7c4cfceb087ac09d6a | 2024-05-27 |
| 0021-Bug-706922-Fix-filenameforall-completion-cleanup.patch | Bug 706922: Fix filenameforall completion cleanup Previously, zfilenameforall() relied upon the specifics of normal interpreter loop operation to correctly cleanup on completion, which works unless the interpreter loop is interrupted by a garbage collection which fails (VMerror). In which case, the top objects on the exec stack are not correctly shuffled around, and the file_cleanup() function ends up being called erroneously with a corrupted file enumerator object which has already been freed anyway. So simply don't use the "trick" and cleanup the stack explicitly before we return to the interpreter loop. |
Chris Liddell <chris.liddell@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=9c24aae232be19ab4e5174578009e8b519d4f3bd | 2023-07-31 |
| 0022-Bug-707007-707015-707025-Don-t-leave-a-dangling-poin.patch | Bug 707007/707015/707025: Don't leave a dangling pointer on the stack At the end of a show operation, we free the enumerator associated with it, and decrement the exec stack pointer - effectively popping the enumerator and various bits of house keeping off the stack. The problem is that in various places the garbage collector works entirely on memory "clumps", and has no concept of where the top of the stacks actually are. As a consequence the freed enumerator's memory can end up being enumerated (marked) and relocated, which obviously leads to problems. In the case of the test file for 707015 on my specific setup, for example, the allocator's memory has be reused to hold a memory rendering device, the mark and reloc corrupt that, which causes a crash when we come to free the device. Note that exactly what gets corrupted depends very much on the memory use at the time which is test file, configuration, platform etc specific. |
Chris Liddell <chris.liddell@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=e7b9aae979e45843a96b862439827682bcfb6ad1 | 2023-08-18 |
| 0023-PostScript-interpreter-Null-dangling-references-on-s.patch | PostScript interpreter - Null dangling references on stack In the wake of bug #707007 it is clear that due ot the way GC works on stack clumps of memory, we cannot leave references to structures which have been explicitly freed on the stacks. So far this only seems to be a problem with the exec stack, because objects on the operand stack are left to GC to free. This commit is the result of reviewing all the places I could find where we allocate a structure on the stack, and then free it explicitly in C rather than leaving it to the garbage collector. |
Ken Sharp <ken.sharp@artifex.com> | no | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=05425198e588427327c55b76dfad57f20f62f944 | 2023-08-21 | |
| 0024-PostScript-interpreter-fix-buffer-length-check.patch | PostScript interpreter - fix buffer length check Bug 707895 See bug report for details. CVE-2024-46956 |
Zdenek Hutyra <zhutyra@centrum.cz> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ea69a1388245ad959d31c272b5ba66d40cebba2c | 2024-07-23 |
| 0025-PS-interpreter-review-colour-code-for-stack-pointers.patch | PS interpreter review colour code for stack pointers No bug report but after the recent slew of fuzzing bugs exploiting incorrect or missing stack checking, a desk check of the colour and colour space code. Mostly the code seems robust, there are a few improvements here; in a couple of places add checks that the operand stack has at least the expected number of operands. A number of places add checks that the exec stack can hold an additional item before incrementing esp. Quite a few places replace explicit decrement of esp with ref_stack_pop() in order to ensure we don't fall off the bottom of a stack block. [Salvatore Bonaccorso: Backport to 10.0.0 for context changes] |
Ken Sharp <ken.sharp@artifex.com> | no | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=f22a42f334b9e7965cb99429b1346346d3e7c2d3 | 2023-08-03 | |
| 0026-PS-interpreter-check-Indexed-colour-space-index.patch | PS interpreter - check Indexed colour space index Bug #707990 "Out of bounds read when reading color in "Indexed" color space" Check the 'index' is in the valid range (0 to hival) for the colour space. Also a couple of additional checks on the type of the 'proc' for Indexed, DeviceN and Separation spaces. Make sure these really are procs in case the user changed the colour space array. CVE-2024-46955 |
Zdenek Hutyra <zhutyra@centrum.cz> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ca1fc2aefe9796e321d0589afe7efb35063c8b2a | 2024-08-30 |
| 0027-PS-interpreter-check-the-type-of-the-Pattern-Impleme.patch | PS interpreter - check the type of the Pattern Implementation Bug #707991 See bug report for details. CVE-2024-46951 |
Zdenek Hutyra <zhutyra@centrum.cz> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ada21374f0c90cc3acf7ce0e96302394560c7aee | 2024-08-30 |
| 0028-PDF-interpreter-sanitise-W-array-values-in-Xref-stre.patch | PDF interpreter - sanitise W array values in Xref streams Bug #708001 "Buffer overflow in PDF XRef stream" See bug report. I've chosen to fix this by checking the values in the W array; these can (currently at least) only have certain relatively small values. As a future proofing fix I've also updated field_size in pdf_xref_stream_entries() to be a 64-bit integer. This is far bigger than required, but matches the W array values and so prevents the mismatch which could lead to a buffer overrun. CVE-2024-46952 |
Ken Sharp <Ken.Sharp@artifex.com> | yes | upstream | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=1fb76aaddac34530242dfbb9579d9997dae41264 | 2024-09-02 |
| 1004_enable_spot_devices.patch | enable DeviceN-related device xcfcmyk | Jonas Smedegaard <dr@jones.dk> | no | 2021-07-18 | ||
| 2001_docdir_fix_for_debian.patch | Set docdir appropriately for Debian | Masayuki Hatta <mhatta@debian.org> | no | 2009-04-15 | ||
| 2002_gs_man_fix_debian.patch | Fixes for gs.1 (Debian specific path adjustments) | Masayuki Hatta <mhatta@debian.org> | no | 2009-04-15 | ||
| 2003_support_multiarch.patch | Check multiarch paths | Jonas Smedegaard <dr@jones.dk> | no | 2011-09-19 | ||
| 2004_remove_non-Debian_paths_from_docs.patch | Remove non-Debian paths from documentation | Bastien ROUCARIÈS <roucaries.bastien@gmail.com> | no | 2012-07-24 | ||
| 2005_fix_Debian_paths_in_docs.patch | Fix Debian paths in documentation | Bastien ROUCARIÈS <roucaries.bastien@gmail.com> | no | 2012-07-24 | ||
| 2006_suggest_install_ghostscript-doc_in_docs.patch | Suggest install of ghostscript-doc in documentation | Bastien ROUCARIÈS <roucaries.bastien@gmail.com> | no | 2012-07-24 | ||
| 2007_suggest_install_ghostscript-doc_in_code.patch | Suggest install of ghostscript-doc in code | Bastien ROUCARIÈS <roucaries.bastien@gmail.com> | no | 2012-07-24 | ||
| 2008_mention_ghostscript-x_in_docs.patch | Mention ghostscipt-x affect on default device in docs | Bastien ROUCARIÈS <roucaries.bastien@gmail.com> | no | 2012-07-24 | ||
| 2010_add_build_timestamp_setting.patch | Allow the build timestamp to be externally set In order to make Ghostscript output reproducible, we need a way to set the build timestamp to other values than the current time. We now consistently use gp_get_realtime() instead of directly calling time() or gp_get_usertime() and make gp_get_realtime() use the value found in the SOURCE_DATE_EPOCH environment variable if set. Also, environment timezone is fixed to UTC if SOURCE_DATE_EPOCH is used to avoid variations. |
Peter De Wachter <pdewacht@gmail.com> | no | debian | 2015-07-30 | |
| 2011_avoid_remote_font.patch | Avoid remote fonts to avoid privacy breach Simply avoid custom fonts for now... | Jonas Smedegaard <dr@jones.dk> | no | 2018-09-14 |
Showing 1 to 39 of 39 entries
All known versions for source package 'ghostscript'
- 10.05.0~dfsg-1 (trixie, sid)
- 10.0.0~dfsg-11+deb12u7 (bookworm-proposed-updates, bookworm-security)
- 10.0.0~dfsg-11+deb12u6 (bookworm)
- 9.53.3~dfsg-7+deb11u9 (bullseye-security)
- 9.53.3~dfsg-7+deb11u7 (bullseye)