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
• 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.
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)
The bug has been referenced in the following commit(s):
Author: Mart Raudsepp <firstname.lastname@example.org>
AuthorDate: 2018-12-19 21:45:35 +0000
Commit: Mart Raudsepp <email@example.com>
CommitDate: 2018-12-19 21:55:44 +0000
dev-libs/glib: security bump to 2.56.4
Signed-off-by: Mart Raudsepp <firstname.lastname@example.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(+)
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.
Will drop 2.58.x older than 2.58.4 in a moment too, to ensure ~arch series doesn't have vulnerable versions.
All arches stable, cleanup done
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).