Bug#933860: pango1.0: CVE-2019-1010238

[Simon McVittie]

https://gitlab.gnome.org/GNOME/pango/issues/342 has now been unembargoed.

On Sun, 04 Aug 2019 at 19:21:29 +0200, Salvatore Bonaccorso wrote:
> Is there some indication which upstream code change introduced
> hte issue so we can try to narrow this down?

Not as far as I can see, but I am not a Pango expert. Perhaps someone
else in the GNOME team has some insight here?

> Re the no-dsa/dsa question, the added severity does not necessarly
> imply that, actually to be on safe side I should have choosen grave
> (which then can be lowered if not appropriate). The problem was simply
> I cannot determine good enough the impact and exploiting/attack
> scenarios.
> 
> Does the upstream bug give more details which can help on that?

The upstream bug reporter writes:

    [The segfault] happens because g_utf8_strlen("\xf8")
    is zero, so n_chars will be zero at this point:
    https://gitlab.gnome.org/GNOME/pango/blob/eb2c647ff693bf3218fd1772f11a008bfbc975e7/pango/pango-bidi-type.c#L173

    But because length = 1, the loop at
    https://gitlab.gnome.org/GNOME/pango/blob/eb2c647ff693bf3218fd1772f11a008bfbc975e7/pango/pango-bidi-type.c#L181
    still executes at least one time, leading to a NULL pointer
    dereference (g_new(.., 0) = NULL)).

    In general, this issue leads to an out-of-bounds heap write and can
    be triggered via pango_itemize if the bytes passed to pango_itemize
    are user-controlled.

I hope that's helpful.

Sorry, I don't know enough about Pango to know whether it's reasonable
to pass malformed UTF-8 to pango_itemize(), or whether this can happen in
practice in (for example) web browsers.

    smcv