bug#63063: CVE-2021-36699 report

[Po Lu]

Eli Zaretskii <eliz@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.