Bug#1067630: Fix arbitrary Lisp execution vulnerability (CVE-2024-30202)
Dear maintainers: This bug report refers to a couple of distinct issues: 1. Evaluating arbitrary Lisp code when a file is opened. 2. Evaluating arbitrary LaTeX code in various circumstances. While the second issue is important to consider, I'd like to focus on the first part. This is a grave security issue affecting Debian stable, and the fix is simple. To check whether or not you have a vulnerable version of org-mode, create a file called "foo.org" containing the following text: #+MACRO: x (eval (syntax-propertize-rules ((insert (upcase "vulnerable\n") Then open foo.org in Emacs. If the word "VULNERABLE" appears, you are using a vulnerable version. Below is the patch from Emacs 29.3 that fixes this bug. It applies cleanly against the version in bookworm (1:28.2+1-15): diff --git a/lisp/org/org-macro.el b/lisp/org/org-macro.el index 776d162..0be51ee 100644 --- a/lisp/org/org-macro.el +++ b/lisp/org/org-macro.el @@ -109,6 +109,13 @@ previous one, unless VALUE is nil. Return the updated list." (let ((new-templates nil)) (pcase-dolist (`(,name . ,value) templates) (let ((old-definition (assoc name new-templates))) +;; This code can be evaluated unconditionally, as a part of +;; loading Org mode. We *must not* evaluate any code present +;; inside the Org buffer while loading. Org buffers may come +;; from various sources, like received email messages from +;; potentially malicious senders. Org mode might be used to +;; preview such messages and no code evaluation from inside the +;; received Org text should ever happen without user consent. (when (and (stringp value) (string-match-p "\\`(eval\\>" value)) ;; Pre-process the evaluation form for faster macro expansion. (let* ((args (org-macro--makeargs value)) @@ -121,7 +128,7 @@ previous one, unless VALUE is nil. Return the updated list." (cadr (read value)) (error (user-error "Invalid definition for macro %S" name) - (setq value (eval (macroexpand-all `(lambda ,args ,body)) t + (setq value `(lambda ,args ,body (cond ((and value old-definition) (setcdr old-definition value)) (old-definition) (t (push (cons name (or value "")) new-templates) Source: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=befa9fcaae29a6c9a283ba371c3c5234c7f644eb Please add this patch to the Emacs source package, and make a security update, as soon as possible.
Bug#884183: linux-image-3.16.0-4-amd64: Kernel panic at boot
On 12/13/17, Benjamin Moody wrote: > Same problem here. 3.16.43-2+deb8u5 works, 3.16.51-2 is broken. > > Supermicro H8QM3 > > Quad-Core AMD Opteron(tm) Processor 8347 HE (fam: 10, model: 02, > stepping: 03) > > Two 3ware 9650SE RAID cards Sorry I didn't think to look for the duplicate bug reports yesterday. I can confirm that: - Version 3.16.51-2 is able to boot if 'numa=off' is specified. - Version 3.16.51-3~a.test (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884069#66) fixes the issue.
Bug#884183: linux-image-3.16.0-4-amd64: Kernel panic at boot
Package: src:linux Followup-For: Bug #884183 Same problem here. 3.16.43-2+deb8u5 works, 3.16.51-2 is broken. Supermicro H8QM3 Quad-Core AMD Opteron(tm) Processor 8347 HE (fam: 10, model: 02, stepping: 03) Two 3ware 9650SE RAID cards I can get the system to boot by doing the following: * installing linux-image-3.16.0-4-amd64_3.16.43-2+deb8u5_amd64.deb (but booting the kernel and initrd from the 3.16.51-2 package) * adding the option 'nosmp' * adding the option 'blacklist=3w-9xxx' If I don't set 'nosmp', the kernel panics immediately. I don't currently have a way to get a serial console on this machine, so I don't have a complete log, but what I can see (https://nofile.io/f/Nfc2FPR83st/IMG_20171213_144202.jpg) appears to match the logs reported by Gerald Schroll. If I set 'nosmp' but not 'blacklist=3w-9xxx', it goes into a seemingly infinite loop (it appears to be trying to initialize one or both RAID cards, but eventually times out and then tries again.) If I set both of those options, the system boots up (slowly), and eventually launches an emergency shell. After five minutes, one of the two RAID devices becomes visible. (I assume that in this case, something is loading 3w-9xxx.ko from the root filesystem, which is version 3.16.43-2+deb8u5.) In case it is useful, below is the log from the *old, working kernel* (3.16.43-2+deb8u5). -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=9927902d-f34d-44ff-b316-b06fdbab989f ro quiet ** Not tainted ** Kernel log: [ 18.018936] [drm] HPD2 [ 18.018938] [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c [ 18.018939] [drm] Encoders: [ 18.018940] [drm] CRT2: INTERNAL_DAC2 [ 18.018942] [drm] DFP2: INTERNAL_DVO1 [ 18.083633] [drm] fb mappable at 0xD004 [ 18.083638] [drm] vram apper at 0xD000 [ 18.083640] [drm] size 786432 [ 18.083641] [drm] fb depth is 8 [ 18.083643] [drm]pitch is 1024 [ 18.083755] fbcon: radeondrmfb (fb0) is primary device [ 18.236979] Console: switching to colour frame buffer device 128x48 [ 18.244485] radeon :01:01.0: fb0: radeondrmfb frame buffer device [ 18.244488] radeon :01:01.0: registered panic notifier [ 18.263937] [drm] Initialized radeon 2.39.0 20080528 for :01:01.0 on minor 0 [ 18.810759] 3w-9xxx: scsi9: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85. [ 18.810764] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85. [ 18.810780] sd 0:0:0:0: [sda] Invalid command failure [ 18.810787] sd 9:0:0:0: [sdb] Invalid command failure [ 18.810790] sd 9:0:0:0: [sdb] [ 18.810793] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 18.810795] sd 9:0:0:0: [sdb] [ 18.810798] Sense Key : Illegal Request [current] [ 18.810806] sd 0:0:0:0: [sda] [ 18.810807] sd 9:0:0:0: [sdb] [ 18.810814] Add. Sense: Invalid command operation code [ 18.810818] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 18.810821] sd 0:0:0:0: [sda] [ 18.810824] Sense Key : Illegal Request [current] [ 18.810829] sd 9:0:0:0: [sdb] CDB: [ 18.810831] ATA command pass through(16): 85 06 [ 18.810837] sd 0:0:0:0: [sda] [ 18.810842] 20 [ 18.810844] Add. Sense: Invalid command operation code [ 18.810846] sd 0:0:0:0: [sda] CDB: [ 18.810848] ATA command pass through(16): 85 [ 18.810853] 00 [ 18.810855] 06 20 00 05 [ 18.810860] 05 [ 18.810861] 00 fe 00 00 [ 18.810867] 00 [ 18.810869] fe [ 18.810871] 00 [ 18.810873] 00 [ 18.810874] 00 [ 18.810876] 00 [ 18.810877] 00 [ 18.810879] 00 [ 18.810880] 40 [ 18.810882] ef [ 18.810883] 00 [ 18.810887] 00 [ 18.810889] 00 00 00 40 ef 00 [ 18.811173] 3w-9xxx: scsi9: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85. [ 18.811231] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85. [ 18.811429] 3w-9xxx: scsi9: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85. [ 18.811498] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85. [ 18.835037] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85. [ 18.835048] sd 0:0:0:0: [sda] Invalid command failure [ 18.835054] sd 0:0:0:0: [sda] [ 18.835056] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 18.835059] sd 0:0:0:0: [sda] [ 18.835061] Sense Key : Illegal Request [current] [ 18.835065] sd 0:0:0:0: [sda] [ 18.835068] Add. Sense: Invalid command operation code [ 18.835071] sd 0:0:0:0: [sda] CDB: [ 18.835073] ATA command pass through(16): 85 06 20 00 05 00 fe 00 00 00 00 00 00 40 ef 00 [ 18.835462] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85. [ 18.835732] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85. [ 19.133918]
Bug#852532: Acknowledgement (olvwm: source code not 64-bit clean, SIGSEGV everywhere)
Unless there is an automated way to identify all the cases of integer/pointer confusion, I don't expect there'll ever be a way to make libxview work on LP64 systems. I am less familiar with olwm/olvwm, but this report is not encouraging. It seems to me that the most sensible thing to do would be to drop the amd64 and other LP64 architectures; for folks who are using olwm/olvwm on amd64, I would recommend installing the i386 version instead (or x32, when that becomes possible.) Benjamin
Bug#846360: libcurl -dev multiarch compatibility
This is a duplicate of bug #731998.
Bug#818821: Fixes for xview build failures on stretch
Here are patches to fix these issues.
First, the use of regexp.h as noted by the submitter.
Second, the use of 'union wait' which is apparently also unsupported
by the glibc in stretch.
Third, the manpage preprocessing error. This is not actually a build
failure (which is presumably a bug in imake.) And of course, using
'cpp' to preprocess man pages seems like an even worse idea than using
it to preprocess Makefiles. But, just in case it'll make somebody
happy, here's a patch to fix that issue.
Description: Use POSIX regular expression API in olvwm.
Do not use the regexp.h functions, which are not available in current
glibc.
--- xview-3.2p1.4.orig/clients/olvwm-4.1/virtual.c
+++ xview-3.2p1.4/clients/olvwm-4.1/virtual.c
@@ -58,9 +58,19 @@ static regexp_err(int val);
#define TRUE 1
#define FALSE 0
+#if 1
+#include
+#define POSIX_REGEXP
+#else
#include
+#endif
+
#ifdef REGEXP
regexp *expbuf;
+#elif defined(POSIX_REGEXP)
+static regex_t expbuf;
+#else
+static char expbuf[256];
#endif
#ifdef IDENT
@@ -2146,14 +2156,14 @@ int val;
}
}
-static char expbuf[256];
-
static
rexMatch(string)
char *string;
{
#ifdef REGEXP
return regexec(expbuf, string);
+#elif defined(POSIX_REGEXP)
+return !regexec(&expbuf, string, 0, NULL, 0);
#else
return step(string,expbuf);
#endif
@@ -2191,6 +2201,8 @@ char newPattern[256];
newPattern[j++] = '\0';
#ifdef REGEXP
expbuf = regcomp(newPattern);
+#elif defined(POSIX_REGEXP)
+regcomp(&expbuf, newPattern, 0);
#else
#if defined(__linux__) && defined(__GLIBC__)
/* See comment above.
Description: Use SysV/POSIX APIs/types in place of some old BSD ones.
Notably, current glibc doesn't support 'union wait'.
--- xview-3.2p1.4.orig/clients/olvwm-4.1/olwm.c
+++ xview-3.2p1.4/clients/olvwm-4.1/olwm.c
@@ -708,7 +708,7 @@ handleChildSignal()
void
ReapChildren()
{
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
pid_t pid;
int status;
#else
@@ -720,7 +720,7 @@ ReapChildren()
if (!deadChildren)
return;
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
sighold(SIGCHLD);
#else
oldmask = sigblock(sigmask(SIGCHLD));
@@ -730,7 +730,7 @@ ReapChildren()
while (1) {
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
pid = waitpid(-1, &status, WNOHANG);
#else
pid = wait3(&status, WNOHANG, (struct rusage *)0);
@@ -757,7 +757,7 @@ ReapChildren()
deadChildren = False;
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
sigrelse(SIGCHLD);
#else
(void) sigsetmask(oldmask);
--- xview-3.2p1.4.orig/clients/olwm/olwm.c
+++ xview-3.2p1.4/clients/olwm/olwm.c
@@ -634,7 +634,7 @@ handleChildSignal()
void
ReapChildren()
{
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
pid_t pid;
int status;
#else
@@ -645,7 +645,7 @@ ReapChildren()
if (!deadChildren)
return;
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
sighold(SIGCHLD);
#else
oldmask = sigblock(sigmask(SIGCHLD));
@@ -655,7 +655,7 @@ ReapChildren()
while (1) {
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
pid = waitpid(-1, &status, WNOHANG);
#else
pid = wait3(&status, WNOHANG, (struct rusage *)0);
@@ -682,7 +682,7 @@ ReapChildren()
deadChildren = False;
-#ifdef SYSV
+#if defined(SYSV) || defined(__linux__)
sigrelse(SIGCHLD);
#else
(void) sigsetmask(oldmask);
--- xview-3.2p1.4.orig/contrib/examples/notifier/ntfy_pipe.c
+++ xview-3.2p1.4/contrib/examples/notifier/ntfy_pipe.c
@@ -161,7 +161,7 @@ Notify_value
sigchldcatcher(client, pid, status, rusage)
Notify_client client; /* the client noted in main() */
int pid; /* the pid that died */
-#ifdef SVR4
+#ifdef SYSV_WAIT
int *status;
#else
union wait *status; /* the status of the process (unused here) */
@@ -169,7 +169,7 @@ union wait *status; /* the status of the
struct rusage *rusage; /* resources used by this process (unused) */
{
if (WIFEXITED(*status)) {
-#ifdef SVR4
+#ifdef SYSV_WAIT
printf("Process termined with status %d\n", *status);
#else
printf("Process termined with status %d\n", status->w_retcode);
--- xview-3.2p1.4.orig/lib/libxview/base/base.h
+++ xview-3.2p1.4/lib/libxview/base/base.h
@@ -63,6 +63,7 @@
#define XV_OS_SVR4
#undef XV_USE_TTCOMPAT
#define SYSV_UCONTEXT
+#define SYSV_WAIT
#define XV_USE_XVFCNTL
#endif
--- xview-3.2p1.4.orig/lib/libxview/misc/expandname.c
+++ xview-3.2p1.4/lib/libxview/misc/expandname.c
@@ -121,11 +121,11 @@ xv_expand_name(name)
length += status;
}
(void) close(pivec[0]);
-#ifndef SVR4
+#ifndef SYSV_WAIT
while (wait((union wait *) & status) != pid);
-#else /* SVR4 */
+#else /* SYSV_WAIT */
while (wait( & status) != pid);
-#endif /* SVR4 */
+#endif /* SYSV_WAIT */
;
status &= 0377;
if (status != 0 && status != SIGPIPE) {
--- xview-3.2p1.4.orig/lib/libxview/notify/ndisd_wait.c
+++ xview-3.2p1.4/lib/libxview/notify/n
Bug#831349: backintime-common: Missing dependency on 'python-dbus' package
Package: backintime-common Version: 1.0.36-1 Severity: grave Justification: renders package unusable Dear Maintainer, The current version of backintime seems to require the 'python-dbus' package: # /usr/bin/backintime --backup-job Traceback (most recent call last): File "/usr/share/backintime/common/backintime.py", line 26, in import config File "/usr/share/backintime/common/config.py", line 30, in import tools File "/usr/share/backintime/common/tools.py", line 27, in import dbus ImportError: No module named dbus This is not marked as a dependency, so the program is completely unusable in a default installation (unless you've installed something else that pulled in python-dbus.) -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages backintime-common depends on: ii cron3.0pl1-127+deb8u1 pn python:any ii rsync 3.1.1-3 backintime-common recommends no packages. Versions of packages backintime-common suggests: pn encfs pn sshfs -- no debconf information
