[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#51105: 29.0.50; Buffer overflow bug in ns_compute_glyph_string_overh
From: |
Daniel Martín |
Subject: |
bug#51105: 29.0.50; Buffer overflow bug in ns_compute_glyph_string_overhangs |
Date: |
Sat, 09 Oct 2021 12:06:36 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (darwin) |
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).