bug#51105: 29.0.50; Buffer overflow bug in ns_compute_glyph_string_overhangs

[Daniel Martín]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 09 Oct 2021 02:30:33 +0200
>> From:  Daniel Martín via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> 2) The root cause of the issue may be that s->nchars is 0 when it
>> shouldn't.  Is there any legitimate scenario where the display engine
>> may call this routine with s->nchars equal to 0? If so, what are those
>> situations?
>
> I think if the glyph string has composition glyphs, nchars can be
> zero.  What is the value of s->first_glyph->type in the case where it
> happens?

Yep, it seems so:

(lldb) fr v s->first_glyph->type
(unsigned int:3) s->first_glyph->type = 1

I've found a 2006 commit that seemed to handle this particular pointer
arithmetic logic for when the type of the first glyph is STRETCH_GLYPH:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=825de9a1027073beaec38ab1572e9d954f8a1eb0

Now I think that the right thing to do may be to modify nsterm.m, switch
on the glyph type and, if the glyph type is COMPOSITE_GLYPH, call
composition_gstring_width to get the glyph metrics.  Function
composition_gstring_width uses the values from fields s->cmp_from and
s->cmp_to, and would avoid the buffer overflow:

(lldb) fr v s->cmp_from
(int) s->cmp_from = 6
(lldb) fr v s->cmp_to
(int) s->cmp_to = 7

WDYT? I can prepare a patch of this type if you agree.

I'll try to get the sequence of codepoints from the glyph string in the
debugger, so we can have a reduced test case (ie. the exact string from
the Wikipedia's front page that causes the issue).