GNOME Bugzilla – Bug 796043
subparse: out-of-bounds array access when fixing SubRip markup
Last modified: 2018-05-12 16:07:06 UTC
Parsing a chunk containing more than 32 unclosed tags will trigger a crash.
Created attachment 371957 [details] [review] patch
Review of attachment 371957 [details] [review]: ::: gst/subparse/gstsubparse.c @@ +759,3 @@ { gchar *cur, *next_tag; + GSList *open_tags = NULL; GSlist sounds a bit suboptimal here, you kind of know that there shouldn't be so many elements (the 32 limit seems to have passed unnoticed for a long time :-)), so avoiding allocating all the time might be better. In practice it might not matter much at all :-) (If it does a GPtrArray could be better). @@ +819,3 @@ if (num_open_tags == 0 + || !g_slist_find_custom (open_tags, tag_name, + (GCompareFunc) g_strcmp0)) { Looks like you are not ignoring the case anymore? @@ -823,3 +824,3 @@ next_tag -= strlen (end_tag); } else { - --num_open_tags; + GSList *first = g_slist_nth (open_tags, 0); Well, that is open_tags itself :-)
Created attachment 371963 [details] [review] updated patch
Review of attachment 371963 [details] [review]: ::: gst/subparse/gstsubparse.c @@ -818,3 +821,3 @@ if (num_open_tags == 0 - || g_ascii_strncasecmp (end_tag - 1, open_tags[num_open_tags - 1], - strlen (open_tags[num_open_tags - 1]))) { + || !g_ptr_array_find_with_equal_func (open_tags, tag_name, + g_str_equal, &index)) { I always have doubt about the use of g_str_equal outside GHashTable, otherwise looks good I think.
Created attachment 371964 [details] [review] updated patch
Review of attachment 371964 [details] [review]: Better, Go :-)