Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 668474

Summary: <dev-libs/glib-2.56.4: multiple vulnerabilities
Product: Gentoo Security Reporter: Thomas Deutschmann <whissi>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Status: RESOLVED FIXED    
Severity: normal CC: gnome
Priority: Normal Flags: stable-bot: sanity-check+
Version: unspecified   
Hardware: All   
OS: Linux   
URL: https://www.openwall.com/lists/oss-security/2018/10/23/5
Whiteboard: A3 [glsa+]
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: ---

Description Thomas Deutschmann gentoo-dev Security 2018-10-12 16:36:00 UTC
Incoming details.
Comment 1 Thomas Deutschmann gentoo-dev Security 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):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0cc2c63d68b910e77f7bbe1bc808d21b7416454e

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

    dev-libs/glib: security bump to 2.56.4
    
    Bug: https://bugs.gentoo.org/668474
    Signed-off-by: Mart Raudsepp <leio@gentoo.org>
    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 2018-12-21 10:16:08 UTC
sparc stable
Comment 7 Thomas Deutschmann gentoo-dev Security 2018-12-22 22:26:04 UTC
x86 stable
Comment 8 Sergei Trofimovich gentoo-dev 2018-12-23 12:10:09 UTC
ia64 stable
Comment 9 Sergei Trofimovich gentoo-dev 2018-12-23 12:10:47 UTC
ppc stable
Comment 10 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2018-12-23 12:23:19 UTC
amd64 stable
Comment 11 Sergei Trofimovich 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 gentoo-dev 2018-12-28 20:00:12 UTC
hppa stable
Comment 14 Mikle Kolyada 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 https://security.gentoo.org/glsa/201904-23
by GLSA coordinator Aaron Bauman (b-man).