Subject: bug#63063: CVE-2021-36699 report

From: Po Lu <[email-masked]>
Date: Tue, 25 Apr 2023 18:55:40 +0800

Eli Zaretskii <[email-masked]> 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.