Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 398359 (CVE-2012-0039) - dev-libs/glib : hash collision DoS (CVE-2012-0039)
Summary: dev-libs/glib : hash collision DoS (CVE-2012-0039)
Alias: CVE-2012-0039
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
Whiteboard: A3 [upstream]
Depends on:
Blocks: hashDoS
  Show dependency tree
Reported: 2012-01-10 10:54 UTC by Agostino Sarubbo
Modified: 2016-03-14 13:22 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2012-01-10 10:54:24 UTC
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.

Comment 1 Alexandre Rostovtsev (RETIRED) gentoo-dev 2012-01-10 19:50:22 UTC
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 (
Comment 2 Aaron Bauman (RETIRED) gentoo-dev 2016-03-14 13:22:58 UTC
** 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.