bug#40913: 24.5; Crash on open of file

bug#40913: 24.5; Crash on open of file

[Jason Gibson]

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

Hello,

Attached is a file that crashes Emacs on find-file (find-file-literally
does not crash).  E.g.:

  tar xf foo8.tar
  LC_CTYPE=en_US.UTF-8 emacs -Q -nw --eval '(find-file "foo8")'
  *poof*

Setting the locale to 'C' makes it not crash.

Reproduction may depend on the environment Emacs was run from.  It has
been shown to crash in screen(1) but sometimes not in xterm directly or
as an X client.  The crashing function is:

  #25 0x000000000048a656 in encode_coding_utf_8 (coding=0x3435d80) at /opt/lude/soft/emacs-25.3/src/private/x86_64_pc_linux_fedora14/../../orig/src/coding.c:1499

Versions checked:

  24.5.1, 26.3, and Git master: 34ae2d0c22 (2020-04-01 22:02:55)

Thanks.

Here's the report-emacs-bug text from Ubuntu 16.04.6 LTS / Emacs 24.5.1:

In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2017-09-20 on lcy01-07, modified by Debian
System Description:     Ubuntu 16.04.6 LTS

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils xterm time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 77557 7390)
 (symbols 48 17639 0)
 (miscs 40 31 88)
 (strings 32 9251 4575)
 (string-bytes 1 249787)
 (vectors 16 7095)
 (vector-slots 8 341333 32687)
 (floats 8 65 369)
 (intervals 56 203 6)
 (buffers 960 11)
 (heap 1024 35092 1893))

This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.


[-- Attachment #2: file that crashes emacs (the untarred content) --]
[-- Type: application/x-tar, Size: 10240 bytes --]

bug#40913: 24.5; Crash on open of file

[Eli Zaretskii]

> From: Jason Gibson <jgibson@perforce.com>
> Date: Mon, 27 Apr 2020 14:31:15 -0700
> 
> Attached is a file that crashes Emacs on find-file (find-file-literally
> does not crash).  E.g.:
> 
>   tar xf foo8.tar
>   LC_CTYPE=en_US.UTF-8 emacs -Q -nw --eval '(find-file "foo8")'
>   *poof*

Thanks.  This is a very old bug, now fixed on the emacs-27 branch.  If
you can build that branch, please see that the crash is gone now.

bug#40913: 24.5; Crash on open of file

[Jason Gibson]

>> From: Jason Gibson <jgibson@perforce.com>
>> Date: Mon, 27 Apr 2020 14:31:15 -0700
>>
>> Attached is a file that crashes Emacs on find-file (find-file-literally
>> does not crash).  E.g.:
>>
>>   tar xf foo8.tar
>>   LC_CTYPE=en_US.UTF-8 emacs -Q -nw --eval '(find-file "foo8")'
>>   *poof*
>
> Thanks.  This is a very old bug, now fixed on the emacs-27 branch.  If
> you can build that branch, please see that the crash is gone now.

The change works for me as well.

Since this would seem to be a good vector for remote buffer overflow, it
might make sense to backport this to prior releases.

Thanks for the quick fix.

This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.

bug#40913: 24.5; Crash on open of file

[Eli Zaretskii]

> From: Jason Gibson <jgibson@perforce.com>
> Cc: 40913@debbugs.gnu.org
> Date: Tue, 28 Apr 2020 09:52:31 -0700
> 
> >>   tar xf foo8.tar
> >>   LC_CTYPE=en_US.UTF-8 emacs -Q -nw --eval '(find-file "foo8")'
> >>   *poof*
> >
> > Thanks.  This is a very old bug, now fixed on the emacs-27 branch.  If
> > you can build that branch, please see that the crash is gone now.
> 
> The change works for me as well.

Thanks, I'm therefore closing the bug.

> Since this would seem to be a good vector for remote buffer overflow, it
> might make sense to backport this to prior releases.

There's no practical way for us to do so, since we do not intend to
put out any new releases of Emacs before 27.  Emacs 27.1 will be
released soon, and this problem will be fixed there.

It is also worth noting that the use case where this bug can rear its
ugly head is quite rare.  Most sequences of composed characters are
very short, and the way we allocate the buffers for them always
allocates more than strictly needed, which is why this bug, although
blatant, went unnoticed for a very long time.  You just happened to
hit a file which (being in fact just a stream of binary bytes) looked
to Emacs as a long sequence of characters all of which should be
composed, and that sequence overflowed the allocated buffer by many
hundreds of bytes, thus triggering memory corruption.

bug#40913: 24.5; Crash on open of file

[Jason Gibson]

>> Since this would seem to be a good vector for remote buffer overflow, it
>> might make sense to backport this to prior releases.
>
> There's no practical way for us to do so, since we do not intend to
> put out any new releases of Emacs before 27.  Emacs 27.1 will be
> released soon, and this problem will be fixed there.
>
> It is also worth noting that the use case where this bug can rear its
> ugly head is quite rare.  Most sequences of composed characters are
> very short, and the way we allocate the buffers for them always
> allocates more than strictly needed, which is why this bug, although
> blatant, went unnoticed for a very long time.  You just happened to
> hit a file which (being in fact just a stream of binary bytes) looked
> to Emacs as a long sequence of characters all of which should be
> composed, and that sequence overflowed the allocated buffer by many
> hundreds of bytes, thus triggering memory corruption.

Sounds good, thanks for the explanations.

This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.