Bug#1070851: glib2.0: minor memory leak after fixing CVE-2024-34397

Salvatore Bonaccorso carnil at debian.org
Fri May 10 16:24:01 BST 2024


Hi Simon,

On Fri, May 10, 2024 at 02:40:48PM +0100, Simon McVittie wrote:
> Source: glib2.0
> Version: 2.74.6-2+deb12u1
> Severity: minor
> Tags: patch fixed-upstream
> X-Debbugs-Cc: security at debian.org
> Control: found -1 2.79.0+git20240110~g38f5ba3c-1
> Control: found -1 2.66.8-1+deb11u2
> Control: fixed -1 2.80.2-1
> 
> While applying the CVE-2024-34397 fixes to glib2.0 in (old)stable,
> I backported an upstream bug fix from GLib 2.79.x to fix a possible
> use-after-free, which had gone undetected in older versions, but caused
> intermittent failures in the new test coverage that I added to reproduce
> CVE-2024-34397.
> 
> It turns out that this bug fix is not 100% correct, and causes a rare
> memory leak: if a program replaces a non-NULL message body with a different
> non-NULL message body, the first argument of the old message body is leaked.
> This has now been fixed upstream and will be in 2.80.3, and I backported
> the fix in 2.80.2-1 (uploaded to unstable today).
> 
> My current understanding is that this will not affect
> typical applications, and only applications that call
> g_dbus_connection_add_filter() and use it to edit incoming or outgoing
> messages in-place will normally be affected. This is not a common pattern,
> and the only real-world use I'm aware of is that stretch's gdm3 had a hack
> that used this to work around an incompatibility between jessie and stretch
> versions' D-Bus APIs during upgrade.
> 
> This is technically a regression in a security update, so I'm cc'ing
> the security team, but I imagine they will not want to update the DSA
> for this. My inclination is to wait for a few days to see whether
> there are any other regressions; if yes, take the opportunity to
> fix this leak at the same time; and otherwise, propose an upload to
> (old)stable-proposed-updates fixing the memory leak.

Right. If we can avoid doing another regression update since this
looks minor, and batch it instead in the point rleases that would be
preferable. Plan sounds good.

Regards,
Salvatore



More information about the pkg-gnome-maintainers mailing list