GNU bug report logs - #63063
CVE-2021-36699 report

Previous Next

Full log

Message #29 received at 63063 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63063 <at> debbugs.gnu.org, fuo <at> fuo.fi
Subject: Re: bug#63063: CVE-2021-36699 report
Date: Tue, 25 Apr 2023 18:55:40 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks, but that seems to be unrelated to the code to which the OP
> pointed.  Are you sure it's the same problem?

Yes: the debugger output isn't very clear because
`dump_make_lv_from_reloc' has been inlined.  Look at the program counter
in the ASAN report.

> Also, writing outside of the process's address space will indeed cause
> protection fault and SIGSEGV, not a buffer-overflow type of problem
> that can be exploited for executing some arbitrary code.  So I'm not
> sure I see why is this a security issue?

The invalid relocation could also point to an address that Emacs has
mapped, but outside any object, in which case AddressSanitizer will
report a buffer overflow.

In either case, this is not a security vulnerability: if you can make
the user load malformed dump files, you can make him load nefarious
executables as well.  It doesn't even qualify as a bug, since malformed
dump files can cause Emacs to crash in a myriad of other ways.

> emacs_ptr_at has this comment:
>
>   /* TODO: assert somehow that the result is actually in the Emacs
>      image.  */
>
> Can we assure that in some reasonable way?  We have valid_pointer_p,
> but that's too expensive, I think.

It's quite expensive.  Any such check should only be turned on
--with-checking.

Previous Next

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