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

[GNU bug Tracking System]

Your message dated Sat, 11 Mar 2023 10:25:34 +0100
with message-id <3624E3C3-1A2F-46A8-9C3B-0AB3CC7E5EC8@acm.org>
and subject line Re: bug#62039: Emacs crashes while parsing a long Emacs Lisp 
string
has caused the debbugs.gnu.org bug report #62039,
regarding Emacs crashes while parsing a long Emacs Lisp string
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
62039: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62039
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: Emacs crashes while parsing a long Emacs Lisp string Date: Tue, 07 Mar 2023 22:51:58 +0100

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.

foo.el.gz
Description: application/gzip

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#62039: Emacs crashes while parsing a long Emacs Lisp string
>
>
>
>
> Date: 
>
> Sat, 11 Mar 2023 10:25:34 +0100
>
>
>
>
> Now fixed on master. Thanks again for the report.
>
>
>
> --- End Message ---