From redhat bugzilla at $URL: It was reported [1] (and the original report [2]) that glib2 also suffers from algorithmic complexity attacks as described in oCERT-2011-003. While this was originally reported to upstream in 2003, it does not look as though anything was done to correct the problem. According to the Debian report, current glib2 is still vulnerable. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655044 [2] http://mail.gnome.org/archives/gtk-devel-list/2003-May/msg00111.html
If any glib-based libraries or applications use g_str_hash() to compare unbounded sets of strings from a potentially hostile source, they need to be fixed to use a different hash function. Fixing g_str_hash() itself is probably not an option since upstream considers its algorithm to be part of the glib API (https://bugzilla.redhat.com/show_bug.cgi?id=772720#c1)
** DISPUTED ** GLib 2.31.8 and earlier, when the g_str_hash function is used, computes hash values without restricting the ability to trigger hash collisions predictably, which allows context-dependent attackers to cause a denial of service (CPU consumption) via crafted input to an application that maintains a hash table. NOTE: this issue may be disputed by the vendor; the existence of the g_str_hash function is not a vulnerability in the library, because callers of g_hash_table_new and g_hash_table_new_full can specify an arbitrary hash function that is appropriate for the application.