In text_to_glyphs in sushi-font-widget.c in gnome-font-viewer 3.34.0, there is a NULL pointer dereference while parsing a TTF font file that lacks a name section (due to a g_strconcat call that returns NULL). Reference: https://gitlab.gnome.org/GNOME/gnome-font-viewer/issues/17 Upstream commit: https://github.com/GNOME/gnome-font-viewer/blob/919dfbe684b75904563b8c6723c9778a4e00aad7/src/sushi-font-widget.c#L115-L117
Created gnome-font-viewer tracking bugs for this issue: Affects: fedora-all [bug 1777939]
Upstream fix: https://gitlab.gnome.org/GNOME/gnome-font-viewer/commit/9661683379806e2bad6a52ce6dde776a33f4f981
While parsing a TTF font file without the name section, function build_strings_for_face() sets the font_name as the result of `g_strconcat(family_name, " ", style_name, NULL)`. Function g_strconcat() concatenates a variable number of arguments until a NULL is found. If the very first argument is NULL, the result is NULL as well. With a specially crafted TTF font file it is possible to make family_name NULL, thus resulting in a NULL font_name which cause a NULL pointer dereference in function text_to_glyphs(), when trying to compute the length of the font_name string.
First vulnerable commit: https://gitlab.gnome.org/GNOME/gnome-font-viewer/commit/7da6cf11bc3a00412a9f9e2073509fd640133e49 which was first introduced in upstream version 3.33.4. This commit removes the NULL checks in sushi_font_widget_size_request() and build_strings_for_face() for family_name and font_name, assuming font_name will always be set. However, the commit does not handle the case where family_name is NULL, thus creating this vulnerability.
This is barely a real security flaw as gnome-font-viewer is not a service, but just a short living program, which is not really impacted by a single crash that cannot be exploited, as a NULL dereference like this.
Statement: This issue did not affect the versions of gnome-font-viewer as shipped with Red Hat Enterprise Linux 7, and 8 as they did not include the vulnerable code.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-19308