Package: glib2.0 Version: 2.66.8-1 Tags: security Are there plans to backport the recent GVariant security fixes to Debian Stable?
These are: - https://gitlab.gnome.org/GNOME/glib/-/issues/2782 - https://gitlab.gnome.org/GNOME/glib/-/issues/2121 - https://gitlab.gnome.org/GNOME/glib/-/issues/2540 - https://gitlab.gnome.org/GNOME/glib/-/issues/2794 - https://gitlab.gnome.org/GNOME/glib/-/issues/2797 - https://gitlab.gnome.org/GNOME/glib/-/issues/2840 - https://gitlab.gnome.org/GNOME/glib/-/issues/2841 In addition, these two issues have highly related fixes (which it’s probably easiest to backport in the same tranche), but they are not security issues: - https://gitlab.gnome.org/GNOME/glib/-/issues/2612 - https://gitlab.gnome.org/GNOME/glib/-/issues/2839 Apologies if a decision has been deliberately taken to not backport them, I don’t fully understand the criteria for what gets backported. --- There are two sets of risks in these issues: 1. Denial of service caused by handling a malicious serialised variant which is structured to cause allocations or looping superlinear to its serialised size. Applications are at risk if they accept untrusted serialised variants by checking them with g_variant_get_normal_form() (or don’t check them). Applications which reject variants with g_variant_is_normal_form() first are not vulnerable. In order to be exploitable, the variant must have a dynamically typed component in it (i.e. a `v` type somewhere). This is typically as part of an `a{sv}`. 2. Denial of service caused by handling a malicious text-form variant which is structured to cause looping superlinear to its text size. Applications are at risk if they parse untrusted text-form variants. Scenario 2 is much less likely than scenario 1, as the GVariant text- form parser is not documented as suitable for use on untrusted input. Scenario 1 is likely because g_variant_get_normal_form() *is* documented as being safe to use on untrusted input. Issue #2840 documents a heap buffer overflow, but this vulnerability was introduced as part of the fixes for the above two scenarious, so GLib is only vulnerable to the overflow if an incomplete set of patches are backported. --- I have a set of backport commits for this for GLib 2.70.4, which we are using in Endless OS. At a quick glance, these commits should also be most of the work needed for backporting to 2.66.8 in Debian Stable. I am happy to help out with this if that’s useful. Philip
