Subject: bug#62039: closed (Re: bug#62039: Emacs crashes while parsing a long Emacs Lisp string)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 11 Mar 2023 09:26:02 +0000

Your bug report

#62039: Emacs crashes while parsing a long Emacs Lisp string

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
62039: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62039
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#62039: Emacs crashes while parsing a long Emacs Lisp string
From: Mattias Engdegård <[email-masked]>
To: Bruno Haible <[email-masked]>
Cc: [email-masked]
Date: Sat, 11 Mar 2023 10:25:34 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Now fixed on master. Thanks again for the report.

Subject: Emacs crashes while parsing a long Emacs Lisp string
From: Bruno Haible <[email-masked]>
To: [email-masked]
Date: Tue, 07 Mar 2023 22:51:58 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

When parsing a particular long Emacs Lisp string, Emacs crashes.

How to reproduce:

$ emacs -Q -batch -f batch-byte-compile foo.el
Segmentation fault

Find attached the compressed file foo.el.

Emacs version: 27.1
Platform: x86_64-linux-gnu
$ ulimit -a | grep stack
stack size                  (kbytes, -s) 8192

According to the documentation
https://www.gnu.org/software/emacs/manual/html_node/emacs/Bug-Criteria.html
any segmentation fault is a bug.

I haven't analyzed the security impact of this bug, but it is quite possible
that emacs receives a string through the network, and even though the string
is not meant to be evaluated, simply parsing it causes a denial-of-service
to the emacs user.

The cause of the bug is that in emacs/src/lread.c the function read_escape()
is recursive, and no bound on the recursion depth is enforced.