Opened 3 years ago

Closed 3 years ago

#14603 closed enhancement (fixed)

glib-2.66.6 (urgent security update)

Reported by: Douglas R. Reno Owned by: Douglas R. Reno
Priority: highest Milestone: 10.1
Component: BOOK Version: SVN
Severity: normal Keywords:


New point version

Change History (12)

comment:1 by Douglas R. Reno, 3 years ago

Priority: normalhighest
Summary: glib-2.66.5glib-2.66.6 (urgent security update)

Now 2.66.6

Classified as Urgent by the maintainer (

Please can people look at it as a matter of urgency, since this is a zero-day (and the new API is also subject to the API freeze on 2021-02-11). Sorry about this.

This is now classified as a zero-day vulnerability. The GitHub Security Team reported it and created an MR, which violates embargo and immediately makes the issue public.

Release notes:


* Fix various instances within GLib where `g_memdup()` was vulnerable to a
  silent integer truncation and heap overflow problem (discovered by
  Kevin Backhouse, work by Philip Withnall) (#2319)

* Bugs fixed:
 - !1927 Backport !1926 “Add g_memdup2()” to glib-2-66

comment:2 by Douglas R. Reno, 3 years ago

Owner: changed from blfs-book to Douglas R. Reno
Status: newassigned

I'll get Jasper and Glib in at my next commit.

comment:3 by Douglas R. Reno, 3 years ago

This is going to be a nightmare for other modules as well. GLib itself will be fixed by this update, but any subsequent modules that use glib are also going to be impacted by this problem. I suspect we'll see a pretty substantial amount of security updates in the next few days.

comment:4 by Tim Tassonis, 3 years ago

I just updated to 2.66.6 on one of my boxed and then got an error in gvfs/gio, so I assume this is gonna require plenty of re-compiles of packages depending on glib.

comment:5 by Douglas R. Reno, 3 years ago

Thank you for the heads up - did recompiling gvfs fix the issue for you?

comment:6 by Douglas R. Reno, 3 years ago

Changelog for 2.66.5:

Overview of changes in GLib 2.66.5

* Fix some issues with handling over-long (invalid) input when parsing for `GDate` (!1824)

* Don’t load GIO modules or parse other GIO environment variables when `AT_SECURE`
  is set (i.e. in a setuid/setgid/setcap process). GIO has always been
  documented as not being safe to use in privileged processes, but people persist
  in using it unsafely, so these changes should harden things against potential
  attacks at least a little. Unfortunately they break a couple of projects which
  were relying on reading `DBUS_SESSION_BUS_ADDRESS`, so GIO continues to read
  that for setgid/setcap (but not setuid) processes. This loophole will be closed
  in GLib 2.70 (see issue #2316), which should give modules 6 months to change
  their behaviour. (Work by Simon McVittie and Philip Withnall) (#2168, #2305)

* Fix `g_spawn()` searching `PATH` when it wasn’t meant to (work by
  Simon McVittie and Thomas Haller) (!1913)

* Bugs fixed:
 - #2168 giomodule: Loads GIO modules even if setuid, etc.
 - #2210 g_private_replace ordering issue
 - #2305 GIO security hardening causing gnome-keyring to regress when session bus is provided by dbus-launch (dbus-x11)
 - !1820 gthread: Destroy value after replacing it in g_private_replace()
 - !1824 Backport !1821 “gdate: Limit length of dates which can be parsed as valid” to glib-2-66
 - !1831 gdatetime.c: Fix MSVC builds for lack of NAN items
 - !1836 Backport !1827 “Windows: fix FD_READ condition flag still set on recoverable UDP socket errors.” to glib-2-66
 - !1864 Backport !1862 “gio: Ignore various environment variables when running as setuid” to glib-2-66
 - !1872 Backport !1868 “gdesktopappinfo: Fix validation of XDG_CURRENT_DESKTOP” to glib-2-66
 - !1913 Backport !1902 “spawn: Don't set a search path if we don't want to search PATH” to glib-2-66
 - !1922 Backport !1920 “Resolve GDBus regressions in setcap/setgid programs” to glib-2-66

Tim, I think your GIO issue might be due to the AT_SECURE thing mentioned in the notes for 2.66.5. I'm in the process of working on this update now (and then JasPer after this, and then commit), so hopefully I'll encounter it and be able to produce some insight. I'm in a full GNOME environment on my dev machine at the moment. I'll also go pay a visit to XFCE prior to committing.

comment:7 by Douglas R. Reno, 3 years ago

Tests look good:

Ok:                 272 
Expected Fail:      0   
Fail:               0   
Unexpected Pass:    0   
Skipped:            0   
Timeout:            0   

Full log written to /sources/glib-2.66.6/glib-2.66.6/build-glib/meson-logs/testlog.txt
156.4 Elasped Time - glib-2.66.6
4732 /sources/glib-2.66.6.tar.xz size (4.621 MB)
215972 kilobytes build size (210.910 MB)
md5sum : fd805b652a0732579eaaafa7a17f90a6  /sources/glib-2.66.6.tar.xz
sha1sum: 29bf4ff76cd9f1060159ee7e2ffb93035adc0c4a  /sources/glib-2.66.6.tar.xz

comment:8 by Douglas R. Reno, 3 years ago

Things seem to be working well for me. This is what I've done:

  • Logged out of my GNOME session, went into LXDE, and then XFCE
  • Verified that Nautilus/Thunar/PCManFM can all mount disks (as well as unmount them)
  • Launched a few random applications in each desktop

I think we're good to go here, but I'd still like to know what's going on with Tim's install. I'll update my machines prior to committing as well just in case any issues come up.

comment:9 by Tim Tassonis, 3 years ago

I think it was maybe just the re-login needed, I could not reproduce the error on two other boxes. Also, the underlying issue might have been that I went from 2.62.3 to 2.66.6 on that box.

I know checked two other boxes with glib/gtk/gvfs/thunar and they were both fine, one also upgrading from 2.62.3, the other from 2.66.4, and both were fine.

So, thumbs up from me, too.

comment:10 by Douglas R. Reno, 3 years ago

Sounds good to me, I will proceed then :-)

If memory serves, there were some minor changes in the runtime behavior of gio between 2.62.x and 2.66.x that might have caused that error briefly

comment:11 by Tim Tassonis, 3 years ago

And just to be absolutely sure, I just restarted the faulty box again, connected to a samba share via thunar/gvfs and this time, it started to play the movie without any error. So even when upgrading from 2.62.3, a restart of gvfs was enough.

comment:12 by Douglas R. Reno, 3 years ago

Resolution: fixed
Status: assignedclosed

Fixed at r24174

Note: See TracTickets for help on using tickets.