bug#30193: The deadliest file in Emacs history

bug#30193: The deadliest file in Emacs history

[積丹尼 Dan Jacobson]

Gentleman, I reveal to you the deadliest file in the history
of Emacs.

It is so deadly that it must be QP encoded, else, well,

Fatal error 11: Segmentation fault
Backtrace:
emacs[0x50a5fe]...
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11fb0)[0x7fc827b75fb0]
/usr/lib/x86_64-linux-gnu/libotf.so.0(OTF_drive_gpos_with_log+0x2a)[0x7fc828527a2a]
/usr/lib/x86_64-linux-gnu/libm17n-flt.so.0(+0x24f2)[0x7fc8280e04f2]...

It is so deadly that once restored from QP, only emacs -nw can safely open it.

If you use X-windows, even doing "! cat"
(! runs the command dired-do-shell-command)
or just plain
$ emacs DEATH
will crash your emacs.
No matter if you do
# su - nobody
or even LC_ALL=C emacs ...
for the cleanest environment.

Oh yeah, here it is.

$ cat DEATH.qp
=E0=B2=B9=E0=B3=86=E0=B2=9A=E0=B3=8D=E0=B2=9A=E0=B3=81

It is so deadly that even in M-x shell,
just doing
$ qprint -d DEATH.qp
will fry your emacs.

emacs-version "25.2.2"
Debian emacs25 25.2+1-6

bug#30193: The deadliest file in Emacs history

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson
> 	<jidanni@jidanni.org>
> Date: Sun, 21 Jan 2018 17:54:25 +0800
> 
> Fatal error 11: Segmentation fault
> Backtrace:
> emacs[0x50a5fe]...
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x11fb0)[0x7fc827b75fb0]
> /usr/lib/x86_64-linux-gnu/libotf.so.0(OTF_drive_gpos_with_log+0x2a)[0x7fc828527a2a]
> /usr/lib/x86_64-linux-gnu/libm17n-flt.so.0(+0x24f2)[0x7fc8280e04f2]...

The crash seems to be inside the libotf/libm17n-flt library; CC'ing
Handa-san who may have comments on this.

Meanwhile, please make sure you have the latest versions of these
libraries installed.

FWIW, it doesn't crash here on MS-Windows, where these libraries are
not used by Emacs.

Thanks.

bug#30193: The deadliest file in Emacs history

[積丹尼 Dan Jacobson]

Package: emacs25
Version: 25.2+1-6
Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Versions of packages emacs25 depends on:
ii  emacs25-bin-common     25.2+1-6
ii  libacl1                2.2.52-3+b1
ii  libasound2             1.1.3-5
ii  libatk1.0-0            2.26.1-2
ii  libc6                  2.26.9000+20180108.401311cf-0experimental0
ii  libcairo-gobject2      1.15.8-3
ii  libcairo2              1.15.8-3
ii  libdbus-1-3            1.12.2-1
ii  libfontconfig1         2.12.6-0.1
ii  libfreetype6           2.8.1-1
ii  libgdk-pixbuf2.0-0     2.36.11-1
ii  libgif7                5.1.4-1
ii  libglib2.0-0           2.55.1-1
ii  libgnutls30            3.6.1-1
ii  libgomp1               8-20180110-1
ii  libgpm2                1.20.7-4
ii  libgtk-3-0             3.22.26-2
ii  libice6                2:1.0.9-2
ii  libjpeg62-turbo        1:1.5.2-2+b1
ii  libm17n-0              1.7.0-3+b2
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-16
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-16
ii  libotf0                0.9.13-3+b1
ii  libpango-1.0-0         1.40.14-1
ii  libpangocairo-1.0-0    1.40.14-1
ii  libpng16-16            1.6.34-1
ii  librsvg2-2             2.40.20-2
ii  libselinux1            2.7-2
ii  libsm6                 2:1.2.2-1+b3
ii  libtiff5               4.0.9-3
ii  libtinfo5              6.0+20171125-1
ii  libx11-6               2:1.6.4-3
ii  libx11-xcb1            2:1.6.4-3
ii  libxcb1                1.12-1
ii  libxfixes3             1:5.0.3-1
ii  libxft2                2.3.2-1+b2
ii  libxinerama1           2:1.1.3-1+b3
ii  libxml2                2.9.7+dfsg-1
ii  libxpm4                1:3.5.12-1
ii  libxrandr2             2:1.5.1-1
ii  libxrender1            1:0.9.10-1
ii  zlib1g                 1:1.2.8.dfsg-5

emacs25 recommends no packages.

Versions of packages emacs25 suggests:
ii  emacs25-common-non-dfsg  25.2+1-1

bug#30193: crash in libotf

[Glenn Morris]

Eli Zaretskii wrote:

> The crash seems to be inside the libotf/libm17n-flt library; CC'ing
> Handa-san who may have comments on this.
>
> Meanwhile, please make sure you have the latest versions of these
> libraries installed.

Still crashes with emacs-26 and latest m17n libs.
(Ie libotf 0.9.13 from 2012 and the m17n 1.8 RC from 2017)

Seems to have been reported multiple times to various downstreams,
who did nothing with the information. Eg

https://bugs.debian.org/826299
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1735167

bug#30193: crash in libotf

[handa]

In article <63zi57dpmv.fsf_-_@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:

> Eli Zaretskii wrote:
> > The crash seems to be inside the libotf/libm17n-flt library; CC'ing
> > Handa-san who may have comments on this.
> >
> > Meanwhile, please make sure you have the latest versions of these
> > libraries installed.

> Still crashes with emacs-26 and latest m17n libs.
> (Ie libotf 0.9.13 from 2012 and the m17n 1.8 RC from 2017)

Sorry for being late.
I've just committed the attached fix to the CVS repository of libotf.
You can get the source by:
  % cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/m17n co libotf

I am going to release the new version of libotf within a few weeks.

---
K. Handa
handa@gnu.org

2018-01-23  K. Handa  <handa@gnu.org>

	* src/otfopen.c (read_class_def): Handle the case of
	f.f1.GlyphCount and f.f2.ClassRangeCount being 0 gracefully.

--- otfopen.c.~1.65.~	2015-03-27 15:14:46.000000000 +0900
+++ otfopen.c	2018-01-23 22:40:04.740168815 +0900
@@ -1040,8 +1040,6 @@
 	= read_glyph_ids (otf, stream,
 			  (OTF_GlyphID **) &class->f.f1.ClassValueArray,
 			  0, -1);
-      if (! class->f.f1.GlyphCount)
-	return -1;
     }
   else if (class->ClassFormat == 2)
     {
@@ -1049,8 +1047,6 @@
 	= read_range_records (otf, stream,
 			      (OTF_RangeRecord **)
 			      &class->f.f2.ClassRangeRecord);
-      if (! class->f.f2.ClassRangeCount)
-	return -1;
     }
   else
     OTF_ERROR (OTF_ERROR_TABLE, " (Invalid format)");

bug#30193: crash in libotf

[Glenn Morris]

Thanks, works for me.
Can anything be done to mitigate this in Emacs?
I expect it will be some time before the fixed libotf becomes the default
in some G/L distributions. Till then, an email can crash Emacs (I
assume) for someone who uses it to read mail.
Can there at least be a PROBLEMS entry?
Does this relate to bug#27836, 28110 at all?

bug#30193: crash in libotf

[handa]

In article <xqpo60gcf4.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:
> Thanks, works for me.

Thank you for confirming that!

> Can anything be done to mitigate this in Emacs?
> I expect it will be some time before the fixed libotf becomes the default
> in some G/L distributions. Till then, an email can crash Emacs (I
> assume) for someone who uses it to read mail.

At the moment, this problem occurs with NotoSerifKannada-Regular.ttf
and NotoSerifKannada-Bold.ttf. So, adding the following code will save
Emacs from crashing.

1. Check the version number of libotf in configure script.
2. Expose that version number to config.h.
3. In xfaces.c, if the version number is less than 0.9.16, initialize
   Vface_ignored_fonts to ("Noto Serif Kannada").

> Can there at least be a PROBLEMS entry?

We can advise (push "Noto Serif Kannada" face-ignored-fonts).

> Does this relate to bug#27836, 28110 at all?

#28110 is surely because of this bug, but as I can't reproduce #27836,
I'm not sure about it.

---
K. Handa
handa@gnu.org

bug#30193: crash in libotf

[Eli Zaretskii]

> From: handa <handa@gnu.org>
> Cc: eliz@gnu.org,  30193@debbugs.gnu.org
> Date: Thu, 25 Jan 2018 18:23:45 +0900
> 
> 1. Check the version number of libotf in configure script.
> 2. Expose that version number to config.h.
> 3. In xfaces.c, if the version number is less than 0.9.16, initialize
>    Vface_ignored_fonts to ("Noto Serif Kannada").

Why not just add that font to face-ignored-fonts by default?

Thanks.

bug#30193: crash in libotf

[handa]

In article <83h8r9na0c.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > 1. Check the version number of libotf in configure script.
> > 2. Expose that version number to config.h.
> > 3. In xfaces.c, if the version number is less than 0.9.16, initialize
> >    Vface_ignored_fonts to ("Noto Serif Kannada").

> Why not just add that font to face-ignored-fonts by default?

For those who build Emacs from source, isn't it better that they do not
have to change Emacs when they build Emacs with the new version of
libotf?

---
K. Handa
handa@gnu.org

bug#30193: crash in libotf

[Eli Zaretskii]

> From: handa <handa@gnu.org>
> Cc: rgm@gnu.org, 30193@debbugs.gnu.org
> Date: Fri, 26 Jan 2018 21:15:38 +0900
> 
> In article <83h8r9na0c.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > 1. Check the version number of libotf in configure script.
> > > 2. Expose that version number to config.h.
> > > 3. In xfaces.c, if the version number is less than 0.9.16, initialize
> > >    Vface_ignored_fonts to ("Noto Serif Kannada").
> 
> > Why not just add that font to face-ignored-fonts by default?
> 
> For those who build Emacs from source, isn't it better that they do not
> have to change Emacs when they build Emacs with the new version of
> libotf?

Why would they need ti change Emacs?  Is Noto Serif Kannada so
important that we cannot reasonably handle the Kannada script without
it?

bug#30193: crash in libotf

[Glenn Morris]

handa wrote:

> 1. Check the version number of libotf in configure script.
> 2. Expose that version number to config.h.
> 3. In xfaces.c, if the version number is less than 0.9.16, initialize
>    Vface_ignored_fonts to ("Noto Serif Kannada").

Thanks, done in 2ce56c51a8.
It seems like a run-time test would be better.
(Will libotf 0.9.16 have an soname version bump?)

bug#30193: crash in libotf

[handa]

In article <ak1sicymx9.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:
> handa wrote:
> > 1. Check the version number of libotf in configure script.
> > 2. Expose that version number to config.h.

Sorry for that.  Directly checking the following macros of <otf.h> is
easier.

/* Version name of this library.  */
#define LIBOTF_VERSION "0.9.15"
/* Major version number.  */
#define LIBOTF_MAJOR_VERSION 0
/* Minor version number.  */
#define LIBOTF_MINOR_VERSION 9
/* Release (i.e. patch level) number.  */
#define LIBOTF_RELEASE_NUMBER 16

> > 3. In xfaces.c, if the version number is less than 0.9.16, initialize
> >    Vface_ignored_fonts to ("Noto Serif Kannada").

> Thanks, done in 2ce56c51a8.
> It seems like a run-time test would be better.
> (Will libotf 0.9.16 have an soname version bump?)

Yes.  The current library is libotf.so.0 (linked to libotf.so.0.0), but
the new one will be libotf.so.1 (linked to libotf.so.1.0.0).

---
K. Handa
handa@gnu.org

bug#30193: crash in libotf

[handa]

In article <83mv10lowq.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > > Why not just add that font to face-ignored-fonts by default?
> > 
> > For those who build Emacs from source, isn't it better that they do not
> > have to change Emacs when they build Emacs with the new version of
> > libotf?

> Why would they need ti change Emacs?  Is Noto Serif Kannada so
> important that we cannot reasonably handle the Kannada script without
> it?

I can not tell how that font is important for Kannada users.

---
K. Handa
handa@gnu.org

bug#30193: crash in libotf

[Glenn Morris]

To summarize:
This is an issue in the libotf library that Emacs uses.
It will be fixed in a future libotf release.
In the meantime, it can be worked around in Emacs by adding
"Noto Serif Kannada" to face-ignored-fonts.

bug#30193: crash in libotf

[handa]

In article <ncshajwd83.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:
> To summarize:
> This is an issue in the libotf library that Emacs uses.
> It will be fixed in a future libotf release.
> In the meantime, it can be worked around in Emacs by adding
> "Noto Serif Kannada" to face-ignored-fonts.

And, the new version of libotf (0.9.16, API version 1.0.0) has been
released along with the m17n library (1.8.0).

---
K. Handa
handa@gnu.org

bug#30193: iOS, Telugu character

[積丹尼 Dan Jacobson]

Ah, reminds me of
http://www.thehindu.com/business/Industry/apple-acknowledges-serious-ios-bug-linked-to-telugu-character/article22772456.ece