GNU bug report logs - #40913
24.5; Crash on open of file

Previous Next

Full log

Message #16 received at 40913-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jason Gibson <jgibson <at> perforce.com>
Cc: 40913-done <at> debbugs.gnu.org
Subject: Re: bug#40913: 24.5; Crash on open of file
Date: Tue, 28 Apr 2020 20:33:47 +0300

> From: Jason Gibson <jgibson <at> perforce.com>
> Cc: 40913 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.