bug#42694: 26.3; Emacs crashes when linked against newer libx11

bug#42694: 26.3; Emacs crashes when linked against newer libx11

[Leo Prikler]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

Two days ago, a patch was sent to Guix updating libx11 to a newer
version in order to fix CVE-2020-14344.  This causes a segmentation
fault in Emacs when trying to start an X window.  After invoking GDB, I
found the offending line to be:

  /* Determine XIC style */
  xic_style = best_xim_style (FRAME_X_XIM_STYLES (f));

For some reason, FRAME_X_XIM_STYLES (f) returns NULL here and
best_xim_style fails when ARRAYELTS is called on it.  I've attached a
patch, that checks for this case.

Regards, 
Leo

[-- Attachment #2: emacs-ignore-empty-xim-styles.patch --]
[-- Type: text/x-patch, Size: 616 bytes --]

Index: emacs-26.3/src/xfns.c
===================================================================
--- emacs-26.3.orig/src/xfns.c
+++ emacs-26.3/src/xfns.c
@@ -2533,6 +2533,8 @@ xic_free_xfontset (struct frame *f)
 static XIMStyle
 best_xim_style (XIMStyles *xim)
 {
+  if (xim == NULL) goto out;
+
   int i, j;
   int nr_supported = ARRAYELTS (supported_xim_styles);
 
@@ -2541,6 +2543,7 @@ best_xim_style (XIMStyles *xim)
       if (supported_xim_styles[i] == xim->supported_styles[j])
 	return supported_xim_styles[i];
 
+ out:
   /* Return the default style.  */
   return XIMPreeditNothing | XIMStatusNothing;
 }

bug#42694: 26.3; Emacs crashes when linked against newer libx11

[Eli Zaretskii]

> From: Leo Prikler <leo.prikler@student.tugraz.at>
> Date: Mon, 03 Aug 2020 11:31:49 +0200
> 
> Two days ago, a patch was sent to Guix updating libx11 to a newer
> version in order to fix CVE-2020-14344.  This causes a segmentation
> fault in Emacs when trying to start an X window.  After invoking GDB, I
> found the offending line to be:
> 
>   /* Determine XIC style */
>   xic_style = best_xim_style (FRAME_X_XIM_STYLES (f));
> 
> For some reason, FRAME_X_XIM_STYLES (f) returns NULL here and
> best_xim_style fails when ARRAYELTS is called on it.  I've attached a
> patch, that checks for this case.

Thanks, this is bug#42676, which was solved yesterday.