This seems to be a pango issue. the invalid write happens in the pango_glyph_item_get_logical_widths function. The function expects the array that's passed in to be item->num_chars * sizeof(int) big (as specified in the documentation), and the caller (PangoLayout) is making the array that's passed in that size, but it then goes and writes an entry one element passed that in the array. The implementation never looks at item->num_chars directly, but through some helpers for iterating over the glyphs. I suppose some invariant has been broken (or something).
reassigning to pango for further analysis by the pango maintainer.
This seems introduced by the negative values in log_clusters array at PangoGlyphString, where is came from hg_glyph->cluster - item_offset in basic_engine_shape in basic-fc.c. in this case hb_glyph->cluster points to 0 even though it isn't a first cluster.
This seems fixed in the harfbuzz git at least.
Reassigning to harfbuzz
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
This seems fixed in harfbuzz upstream.
Created attachment 917005 [details]
fix this bug
the upstream patch link is http://cgit.freedesktop.org/harfbuzz/commit/?id=6ae13f257c3986517c097fa666ab9f58bdc918b5 which is same what we want to use for this bug.
built the fix in harfbuzz-0.9.20-4.el7
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.