Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 668474 - <dev-libs/glib-2.56.4: multiple vulnerabilities
Summary: <dev-libs/glib-2.56.4: multiple vulnerabilities
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
Whiteboard: A3 [glsa+]
Depends on:
Reported: 2018-10-12 16:36 UTC by Thomas Deutschmann (RETIRED)
Modified: 2019-04-22 23:37 UTC (History)
1 user (show)

See Also:
Package list:
dev-libs/glib-2.56.4 dev-util/gdbus-codegen-2.56.4 dev-util/glib-utils-2.56.4
Runtime testing required: ---
stable-bot: sanity-check+


Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Deutschmann (RETIRED) gentoo-dev 2018-10-12 16:36:00 UTC
Incoming details.
Comment 1 Thomas Deutschmann (RETIRED) gentoo-dev 2018-12-17 13:48:08 UTC
From $URL:

In brief, the problems fixed are:
 • Arithmetic underflow when calculating GVariant tuple element ends
resulting from missing validation of the offset table. This can result
in an out of bound read. Fixed by adding validation.
 • Unbounded call recursion when handling highly recursive GVariant
types. This can result in a call stack overflow. Fixed by limiting
GVariant type recursion with static and dynamic types in untrusted
GVariant instances.
 • Infinite loop when getting a child from a serialised variable array,
due to missing validation that the child offset does not point into the
offset table itself. Fixed by adding validation.
 • Similarly for serialised tuples.
 • nul bytes could pass through UTF-8 validation for long GVariant
strings due to a signed/unsigned mismatch. Fix: add a new validation
function which operates on an unsigned string length.
 • Critical warning when parsing a D-Bus message with the wrong type
for its signature field in its message header. Fix: validate the type
before unwrapping that field.
 • Critical warning when parsing a D-Bus message with a header field
containing a variant with an empty type signature, due to a mismatch
between validation of D-Bus type signatures and validation of GVariant
type strings. Fix: validate that the field is a valid type string too.
Comment 2 Mart Raudsepp gentoo-dev 2018-12-17 17:59:44 UTC
Partial cherry-picks ended up with test failures, so weren't included in 2.58.1 bump. Upstream hopes to finally get around to releasing 2.58.2 tomorrow, which will include these, and hopefully tests don't fail when all the changes are included.
I'm not yet sure what to do with stable tree - if worth updating or not. Upstream 2.56 branch does have the commits, but might not get all follow-ups that are still to be included in 2.58.2 backported into there. I guess we'll see. 2.58 is too early to go stable, even if for "security" (oss-fuzz test that are only DoS and probably hard to get users to hit it with local data)
Comment 3 Larry the Git Cow gentoo-dev 2018-12-19 21:56:29 UTC
The bug has been referenced in the following commit(s):

commit 0cc2c63d68b910e77f7bbe1bc808d21b7416454e
Author:     Mart Raudsepp <>
AuthorDate: 2018-12-19 21:45:35 +0000
Commit:     Mart Raudsepp <>
CommitDate: 2018-12-19 21:55:44 +0000

    dev-libs/glib: security bump to 2.56.4
    Signed-off-by: Mart Raudsepp <>
    Package-Manager: Portage-2.3.52, Repoman-2.3.11

 dev-libs/glib/Manifest           |   1 +
 dev-libs/glib/glib-2.56.4.ebuild | 300 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 301 insertions(+)
Comment 4 Mart Raudsepp gentoo-dev 2018-12-19 22:01:01 UTC
I've fixed the new gvariant 32bit test failure upstream, added patch to 2.58.2 and 2.56.4 bumps and now we should be able to stabilize the freshly baked 2.56.4, which I believe should include the relevant commits from upstream backports.
There may be test failures relating to appinfo/launch* and desktop-app-info/launch* but that is not a regression. Those tests are skipped in 2.58 with pending upstream improvements that might allow to re-enable, but this change wasn't done to 2.56 bumps anymore on purpose, as I'm not in a good position to test them anymore, being on 2.58 myself.
Comment 5 Mart Raudsepp gentoo-dev 2018-12-19 22:02:01 UTC
Will drop 2.58.x older than 2.58.4 in a moment too, to ensure ~arch series doesn't have vulnerable versions.
Comment 6 Rolf Eike Beer archtester 2018-12-21 10:16:08 UTC
sparc stable
Comment 7 Thomas Deutschmann (RETIRED) gentoo-dev 2018-12-22 22:26:04 UTC
x86 stable
Comment 8 Sergei Trofimovich (RETIRED) gentoo-dev 2018-12-23 12:10:09 UTC
ia64 stable
Comment 9 Sergei Trofimovich (RETIRED) gentoo-dev 2018-12-23 12:10:47 UTC
ppc stable
Comment 10 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2018-12-23 12:23:19 UTC
amd64 stable
Comment 11 Sergei Trofimovich (RETIRED) gentoo-dev 2018-12-25 20:07:08 UTC
ppc64 stable
Comment 12 Matt Turner gentoo-dev 2018-12-26 17:17:52 UTC
alpha stable
Comment 13 Sergei Trofimovich (RETIRED) gentoo-dev 2018-12-28 20:00:12 UTC
hppa stable
Comment 14 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2018-12-30 18:04:34 UTC
s390 stable
Comment 15 Markus Meier gentoo-dev 2019-01-02 12:16:30 UTC
arm stable
Comment 16 Mart Raudsepp gentoo-dev 2019-01-03 20:15:40 UTC
arm64 stable
Comment 17 Mart Raudsepp gentoo-dev 2019-01-03 20:16:30 UTC
All arches stable, cleanup done
Comment 18 GLSAMaker/CVETool Bot gentoo-dev 2019-04-22 23:37:23 UTC
This issue was resolved and addressed in
 GLSA 201904-23 at
by GLSA coordinator Aaron Bauman (b-man).