http://bugs.winehq.org/show_bug.cgi?id=59532 Bug ID: 59532 Summary: Integer underflow in uniscribe implementation Product: Wine Version: 11.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs@list.winehq.org Reporter: dsf190@me.com Distribution: --- Created attachment 80567 --> http://bugs.winehq.org/attachment.cgi?id=80567 segfault recorded by gdb https://github.com/ValveSoftware/Proton/issues/58#issuecomment-4040483961 Two example strings to cause this behavior are: @ฺxฺ $ำำx In gdi32/uniscribe/opentype.c, GPOS_apply_MarkToMark can underflow and cause an out of bounds read. If we try to run @ฺxฺ through, ScriptItemize (usp10.c) will break the string into 2 runs, one containing latin "x" and one containing the thai marks. See this line from GPOS_apply_MarkToMark: mark2_index = GSUB_is_glyph_covered((const BYTE*)mmpf1+offset, glyphs[glyph_index - write_dir]); When the run containing only the thai marks is passed here, the glyph_index (unsigned int) is evaluated to 0, and since thai is a LTR language, write_dir (signed int) is set to 1, resulting in 0 (unsigned) - 1 (signed). Since the 0 is unsigned the result would be an underflow and the program trying to evaluate glyphs[4294967295], causing the segfault in the attachment. It's likely that GPOS_apply_MarkToBase and GPOS_apply_MarkToLigature have similar assumptions that marks will never be alone in a run and/or set to the 0th position of the run's array. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.