| Summary: | <dev-libs/glib-2.56.4: multiple vulnerabilities | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Thomas Deutschmann (RETIRED) <whissi> |
| Component: | Vulnerabilities | Assignee: | 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 (RETIRED)
2018-10-12 16:36:00 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. 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): 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(+) 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. sparc stable x86 stable ia64 stable ppc stable amd64 stable ppc64 stable alpha stable hppa stable s390 stable arm stable arm64 stable 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). |
