Processed: Re: Bug#944760: ghostscript: CVE-2019-14869
Processing control commands: > severity -1 important Bug #944760 [src:ghostscript] ghostscript: CVE-2019-14869 Severity set to 'important' from 'grave' -- 944760: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944760 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#944760: ghostscript: CVE-2019-14869
Control: severity -1 important Quoting Salvatore Bonaccorso (2019-11-14 22:47:49) > Source: ghostscript > Version: 9.50~dfsg-2 > Severity: grave > Tags: security upstream > Control: found -1 9.26a~dfsg-0+deb9u5 > Control: found -1 9.26a~dfsg-0+deb9u1 > Control: found -1 9.27~dfsg-2+deb10u2 > Control: found -1 9.27~dfsg-1 > Control: found -1 9.27~dfsg-3.1 > Control: fixed -1 9.26a~dfsg-0+deb9u6 > Control: fixed -1 9.27~dfsg-2+deb10u3 > > Hi, > > The following vulnerability was published for ghostscript. I can agree > the severity is not exaclty matching, as for 9.50 itself, it's not > anymore directly exploitable (unless with -dOLDSAFER). Still it cannot > be considred fixed, only after applying [1]. Lowering severity to avoid this blocking more grave security fixes entering testing. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#843324: marked as done (ghostscript crashes on some machines, much of the time)
Your message dated Mon, 18 Nov 2019 22:30:07 +0100
with message-id <157411260768.238883.8182046441171275...@auryn.jones.dk>
and subject line Re: Bug#843324: ghostscript crashes on some machines, much of
the time
has caused the Debian Bug report #843324,
regarding ghostscript crashes on some machines, much of the time
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
843324: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843324
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: ghostscript
Version: 9.06~dfsg-2+deb8u4
Tags: patch
Severity: serious
Control: fixed -1 9.19~dfsg-3.1
On some machines, with recent jessie libcs, on amd64 Linux (at least),
ghostscript crashes because it unlocks an already-unlocked pthread
DEFAULT mutex. (Well, actually, in my test case, it locks it twice,
and then unlocks it twice.)
This is the upstream bug:
http://bugs.ghostscript.com/show_bug.cgi?id=695862
It can be fixed by cherry-picking the corresponding upstream patch,
444e0bf9c43b "Bug 695862: use PTHREAD_MUTEX_RECURSIVE(_NP) if available"
Please find attached a suitable backport. I threw away the changes to
the configure and build system. We do not need these because we
always have recursive mutexes available: so instead, I just definen
the appropriate preprocessor symbol in the file which uses it.
Thanks.
Ian.
>From f96eb410d8c1b6f7660638c39c9add82be158d94 Mon Sep 17 00:00:00 2001
From: Chris Liddell
Date: Mon, 16 Mar 2015 12:52:49 +
Subject: [PATCH] Bug 695862: use PTHREAD_MUTEX_RECURSIVE(_NP) if available
or properly emulate recursive mutexes ourselves.
No cluster differences
(cherry picked from commit 444e0bf9c43bae0261660e6318ba0e514c18d41e)
Conflicts:
config.mak.in
configure.ac
gs/Makefile.in
gs/configure.ac
[ Dropped all the buildsystem and configure changes. Instead,
we just hardcode GS_RECURSIVE_MUTEXATTR since it will
always be available on Debian. -iwj ]
---
base/gp_psync.c | 71 +++--
1 file changed, 59 insertions(+), 12 deletions(-)
diff --git a/base/gp_psync.c b/base/gp_psync.c
index 60f6977..d09871b 100644
--- a/base/gp_psync.c
+++ b/base/gp_psync.c
@@ -13,6 +13,7 @@
CA 94903, U.S.A., +1(415)492-9861, for further information.
*/
+#define GS_RECURSIVE_MUTEXATTR 1 /* always, on Debian */
/* POSIX pthreads threads / semaphore / monitor implementation */
#include "std.h"
@@ -128,13 +129,20 @@ gp_semaphore_signal(gp_semaphore * sema)
/* Monitor supports enter/leave semantics */
/*
- * We need PTHREAD_MUTEX_RECURSIVE behavior, but this isn't totally portable
- * so we implement it in a more portable fashion, keeping track of the
- * owner thread using 'pthread_self()'
+ * We need PTHREAD_MUTEX_RECURSIVE behavior, but this isn't
+ * supported on all pthread platforms, so if it's available
+ * we'll use it, otherwise we'll emulate it.
+ * GS_RECURSIVE_MUTEXATTR is set by the configure script
+ * on Unix-like machines to the attribute setting for
+ * PTHREAD_MUTEX_RECURSIVE - on linux this is usually
+ * PTHREAD_MUTEX_RECURSIVE_NP
*/
typedef struct gp_pthread_recursive_s {
pthread_mutex_t mutex; /* actual mutex */
+#ifndef GS_RECURSIVE_MUTEXATTR
pthread_t self_id;/* owner */
+int lcount;
+#endif
} gp_pthread_recursive_t;
uint
@@ -148,12 +156,32 @@ gp_monitor_open(gp_monitor * mona)
{
pthread_mutex_t *mon;
int scode;
+pthread_mutexattr_t attr;
+pthread_mutexattr_t *attrp = NULL;
if (!mona)
return -1; /* monitors are not movable */
-mon = &((gp_pthread_recursive_t *)mona)->mutex;
+
+
+#ifdef GS_RECURSIVE_MUTEXATTR
+attrp = &attr;
+scode = pthread_mutexattr_init(attrp);
+if (scode < 0) goto done;
+
+scode = pthread_mutexattr_settype(attrp, GS_RECURSIVE_MUTEXATTR);
+if (scode < 0) {
+goto done;
+}
+#else
((gp_pthread_recursive_t *)mona)->self_id = 0; /* Not valid unless
mutex is locked */
-scode = pthread_mutex_init(mon, NULL);
+((gp_pthread_recursive_t *)mona)->lcount = 0;
+#endif
+
+mon = &((gp_pthread_recursive_t *)mona)->mutex;
+scode = pthread_mutex_init(mon, attrp);
+if (attrp)
+(void)pthread_mutexattr_destroy(attrp);
+done:
return SEM_ERROR_CODE(scode);
}
@@ -173,29 +201,48 @@ gp_monitor_enter(gp_monitor * mona)
pthread_mutex_t * const mon = (pthread_mutex_t *)mona;
int scode;
+#ifdef GS_RECURSIVE_MUTEXATTR
+scode = pthread_mutex_lock(mon);
+#else
if ((scode = pthread_mutex
Processed: Re: Bug#940127: ghostscript makes c2esp autopkgtest timeout
Processing control commands: > severity -1 important Bug #940127 [src:ghostscript, src:c2esp] gs segfaults in c2esp filter chain Severity set to 'important' from 'serious' -- 940127: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940127 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#940127: ghostscript makes c2esp autopkgtest timeout
Control: severity -1 important Quoting Jonas Smedegaard (2019-11-14 14:28:35) > @Didier: Since you reassigned this to (only) ghostscript, would you > please consider re-reassigning to (only) c2esp instead? > > Reason I ask is that ghostscript is now security-buggy in testing > since a month, seemingly blocked only by this issue. If reassigning > does not seem sensible, then how about lowering severity (maybe only > temporarily)? Lowering severity to prioritize general security over use with c2esp. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
[bts-link] source package cups
# # bts-link upstream status pull for source package cups # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #799042 (http://bugs.debian.org/799042) # Bug title: cups-client: lpoptions no longer outputs anything # * https://github.com/apple/cups/issues/5681 # * remote status changed: open -> closed usertags 799042 - status-open usertags 799042 + status-closed thanks
Bug#819611: marked as done (libcupsfilters-dev: #include should be #include )
Your message dated Mon, 18 Nov 2019 12:08:05 + with message-id <18112019120642.78e5c0917...@desktop.copernicus.org.uk> and subject line Re: Bug#819611: libcupsfilters-dev: #include should be #include has caused the Debian Bug report #819611, regarding libcupsfilters-dev: #include should be #include to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 819611: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819611 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libcupsfilters-dev Version: 1.0.61-5+deb8u3 Severity: normal Dear Maintainer, * What led up to the situation? trying to compile and install the Perl module Net::CUPS::Destination * What exactly did you do (or not do) that was effective (or ineffective)? raster.h has been moved from /usr/include/cups to /usr/include/cupsfilters but the cups header files still try and #include it as cups/raster.h see /usr/include/cupsfilters/*.h image.h, driver.h, colormanger.h and raster.h have the wrong path. -- System Information: Debian Release: 8.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libcupsfilters-dev depends on: ii libcupsfilters1 1.0.61-5+deb8u3 libcupsfilters-dev recommends no packages. libcupsfilters-dev suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- No activity for three years. Closing. Regards, Brian.--- End Message ---
