[Bug 59532] New: Integer underflow in uniscribe implementation

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
      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.