Fedora has issued an advisory on February 8: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/RKZC2OMFCXQTQDGIDS4JBWOWNQUAAOV2/ The update has already been in SVN but freeze pushes were ignored. Mageia 8 is therefore affected. Mageia 7 may be as well. Additionally, an issue fixed in 2.63.6 is discussed in this thread: https://www.openwall.com/lists/oss-security/2021/02/09/4
Whiteboard: (none) => MGA8TOO, MGA7TOO
Assigning to Olav as you have done many commits of this recently, so it is not unknown to you.
Assignee: bugsquad => olav
as I responded on the freeze push request, they were not ignored, they were intentionally postponed as the changes was no-where tested enoungh to do land in a release freezed distro, and also had upstream comments " Unfortunately they break a couple of projects ..." And as it turns out it was definately the correct decision, something confirmed as upstream had to release a followup 2.66.7: https://gitlab.gnome.org/GNOME/glib/-/commit/95115f029d9c170c2e966cd7d3547b6394c92a4a especially this: * Fix various regressions caused by *rushed* security fixes in 2.66.6 (work by Simon McVittie and Jan Alexander Steffens) (!1933, !1943) and as I outlined back then, the way forward is to land it in cauldron first, see ahat breaks... after that land it in stable releases...
glib2.0-2.66.7-1.mga9 mingw-glib2-2.66.7-1.mga9 pushed to Cauldron
Whiteboard: MGA8TOO, MGA7TOO => MGA7TOOVersion: Cauldron => 8
(In reply to Thomas Backlund from comment #3) > glib2.0-2.66.7-1.mga9 > mingw-glib2-2.66.7-1.mga9 > > pushed to Cauldron I see that the mga suffix is still .mga8 and not .mga9
CC: (none) => geiger.david68210
yeah, a missing config update made them show up as mga8 in web, but they are mga9 rpms in reality... As soon as last puppet run is finalized it should all be ok and caulron reopened
Fedora has issued an advisory for this on February 14: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/F3TX2KSXDNFQN6HBKCYRZSZWKF4W5EYJ/
Built by Thomas for Mageia 8: glib2.0-tests-2.66.7-1.mga8 libglib2.0-static-devel-2.66.7-1.mga8 glib2.0-common-2.66.7-1.mga8 libglib2.0_0-2.66.7-1.mga8 libgio2.0_0-2.66.7-1.mga8 glib-gettextize-2.66.7-1.mga8 libglib2.0-devel-2.66.7-1.mga8 mingw64-glib2-2.66.7-1.mga8 mingw32-glib2-2.66.7-1.mga8 mingw32-glib2-static-2.66.7-1.mga8 mingw64-glib2-static-2.66.7-1.mga8 from SRPMS: glib2.0-2.66.7-1.mga8.src.rpm mingw-glib2-2.66.7-1.mga8.src.rpm
yep, I will run it for some days on my mga8 systems here to see if anything breaks... seems debian got some trouble with atleast gnome-keyring and dbus-x11... so we need to verify that those are not affected for us... as for mga7 I'm not sure yet if we should try to fix all of theese "security issues" as they esentially change an "valid" api to behave differently as part of locking down stuff for theoretical exploits... mga7 has glib2.0 2.60 and mingw-glib2 2.58, so it can turn out to be "fun" to backport the all fixes... and since our other packages in mga7 are old... chances for them hitting more issues are bigger than mga8 that is somewhat uptodate...
Yeah, we may have to clone this bug and see later if upstream or another distro backports any relevant fixes.
(In reply to David Walser from comment #9) > Yeah, we may have to clone this bug and see later if upstream or another > distro backports any relevant fixes. Doing so, cloning this for Mageia 7. Assigning this to QA. Suggested Advisory: ======================== Updated glib packages fix security vulnerabilities: * 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) * 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) Also, this update provides 2.66.7 version that fixes several issues: * Fix various regressions caused by rushed security fixes in 2.66.6 (work by Simon McVittie and Jan Alexander Steffens) (!1933, !1943) * Fix a silent integer truncation when calling `g_byte_array_new_take()` for byte arrays bigger than `G_MAXUINT` (work by Krzesimir Nowak) (!1944) * Disallow using currently-undefined D-Bus connection or server flags to prevent forward-compatibility problems with new security-sensitive flags likely to be released in GLib 2.68 (work by Simon McVittie) (!1945) * Bugs fixed: - !1933 [2.66] Fix regressions in 2.66.6 where negative gssize indicates strlen() - !1943 Backport !1941 “gkeyfilesettingsbackend: Fix basename handling when group is unset” to glib-2-66 - !1944 Backport !1942 “gbytearray: Do not accept too large byte arrays” to glib-2-66 - !1945 Backport !1934 “gdbus: Reject attempts to set future connection or server flags” to glib-2-66 References: - https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/RKZC2OMFCXQTQDGIDS4JBWOWNQUAAOV2/ - https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/F3TX2KSXDNFQN6HBKCYRZSZWKF4W5EYJ/ ======================== Updated packages in core/updates_testing: ======================== glib2.0-tests-2.66.7-1.mga8 libglib2.0-static-devel-2.66.7-1.mga8 glib2.0-common-2.66.7-1.mga8 libglib2.0_0-2.66.7-1.mga8 libgio2.0_0-2.66.7-1.mga8 glib-gettextize-2.66.7-1.mga8 libglib2.0-devel-2.66.7-1.mga8 mingw64-glib2-2.66.7-1.mga8 mingw32-glib2-2.66.7-1.mga8 mingw32-glib2-static-2.66.7-1.mga8 mingw64-glib2-static-2.66.7-1.mga8 from SRPMS: glib2.0-2.66.7-1.mga8.src.rpm mingw-glib2-2.66.7-1.mga8.src.rpm
CC: (none) => ouaurelienSee Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=28520Assignee: olav => qa-bugsStatus: NEW => ASSIGNEDWhiteboard: MGA7TOO => (none)
mga8, x64 Before updating glib2 noted that geequie depends on it and that RedHat had a bug: Bug #1927052 - Geeqie is not responding when started with the -r (--remote) option Checked that by opening geeqie in a Pictures directory then going to another teminal and typing: $ geeqie -r --next That command could be typed several times and each time the next image was displayed, so that particular bug is confined to starting only. $ geeqie -r ~/Pictures Remote Geeqie not running, starting... It did in fact start and responded to the `geeqie -r -n` command. So the bug had already been fixed. Consulted an earlier bug for enlightenment: https://bugs.mageia.org/show_bug.cgi?id=23665 $ gcc -g -o test2 test2.c `pkg-config --cflags --libs glib-2.0` $ ./test2 input Error: (null) $ gcc -g -O0 -Llibasan2 -fomit-frame-pointer -o test3 test2.c `pkg-config --cflags --libs glib-2.0` test3 issues the same error as test2. Running it under valgrind pinpoints an error. All these show is that runnable object files can be compiled. asan can be incorporated also. Found some scripts used before and compiled them. Don't know where they came from. $ gcc -g -o atomic glib_atomic.c `pkg-config --cflags --libs glib-2.0` $ ./atomic glib_atomic.c: atomic tests using glib Test 1 using g_atomic_int_compare_and_exchange() Thread 2 elapsed=0.651980 Thread 1 elapsed=0.708055 Misses=4943305 Test 2 using g_atomic_int_set() Thread 2 elapsed=0.695462 Thread 1 elapsed=0.695650 glib_hash.c compiled but issued many 'deprecated' warnings, suggesting alternative functions. $ ./hash glib_hash.c: test glib's hash and other fcns 2021-03-09T09:43:59.716732Z error opening DICx d=1 code=4, msg=No such file or directory Read 483523 in 0.116991 Found key=Linux with value (null) in 0.000001 Found key=joker with value joker in 0.000000 Found key=joke with value joke in 0.000000 Found key=secret with value secret in 0.000000 Finding string using g_hash_table_foreach() Finding string using g_hash_table_find() Found (null) Tried glib_main_loop1 and ...loop2. Not sure how they were supposed to be run. $ ./main_loop1 1615283159.676829: Starting 1615283164.863077: callback_function [...] 1615283219.862014: callback_function 1615283224.862818: callback_function ^C $ ./main_loop2 1615284018.381824: main: STARTING 1615284018.381846: main: creating main context, TMO=5 1615284018.381879: main: creating loop1 context, TMO=10 1615284018.381940: main: creating loop2 context, TMO=3 1615284018.381982: idle_func: ENTERED D=LOOP_1 1615284018.381984: idle_func: EXITING 1615284018.381990: loop_thread: STARTING [...] 1615284018.382040: idle_func: EXITING 1615284021.385081: tmo_callback: tmo_loop2_callback 1615284023.863535: tmo_callback: tmo_callback [...] ^C Compiled and ran ghiper.c, glib_async_queue.c and glib_test1.c. $ ./test1 Init: called Hello th1: ii=1 vv=2 [...] th1: ii=10 vv=31 Cleanup: called Cleanup: joined with thread Done $ gcc -g -o hiper ghiper.c `pkg-config --cflags --libs glib-2.0` /usr/bin/ld: /tmp/ccguaFZk.o: in function `check_multi_info': /home/lcl/dev/glib2/ghiper.c:131: undefined reference to `curl_easy_getinfo' /usr/bin/ld: /home/lcl/dev/glib2/ghiper.c:132: undefined reference to `curl_easy_getinfo' <Should we be concerned?> $ ./asyncq 1615284692.584889 Sending Q 1615284692.584957 TH1 MSG: AAA [1615284692.584819] 1615284692.584966 TH1 MSG: AAB [1615284692.584879] 1615284692.584968 TH1 MSG: AAC [1615284692.584882] 1615284692.584970 TH1 MSG: Q [1615284692.584917] 1615284692.584970 TH1 DONE! 1615284692.585145 Joined thread, exiting Updated glib2 the mingw packages and ran the geeqie test. (medium "Core Updates Testing") glib-gettextize 2.66.7 1.mga8 x86_64 glib2.0-common 2.66.7 1.mga8 x86_64 glib2.0-tests 2.66.7 1.mga8 x86_64 lib64gio2.0_0 2.66.7 1.mga8 x86_64 lib64glib2.0-devel 2.66.7 1.mga8 x86_64 lib64glib2.0-static-devel 2.66.7 1.mga8 x86_64 lib64glib2.0_0 2.66.7 1.mga8 x86_64 mingw64-glib2 2.66.7 1.mga8 noarch mingw64-glib2-static 2.66.7 1.mga8 noarch mingw32-glib2 2.66.7 1.mga8 noarch mingw32-glib2-static 2.66.7 1.mga8 noarch $ geeqie -r Remote Geeqie not running, starting... The application appeared in the workspace last used for geeqie, pointing at the home directory. Navigated to the Pictures directory then returned to the launch terminal. $ geeqie -r -n That switched the view to the next image in the directory. Recompiled and tested the specimen program scripts. ghiper failed again to compile and glib_hash issued warnings. When run, the executables returned the same results as before. lilypond is listed in 'whatrequires'. $ strace -o lilypond.trace lilypond lily-0dae7688.ly GNU LilyPond 2.20.0 Processing `lily-0dae7688.ly' Parsing... Renaming input to: `/home/gub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.18/input/regression/accidental-contemporary.ly' Interpreting music... Preprocessing graphical objects... Interpreting music... Preprocessing graphical objects... Calculating line breaks... Drawing systems... Calculating line breaks... Drawing systems... Layout output to `lily-0dae7688.eps'... Converting to `lily-0dae7688.pdf'... Deleting `lily-0dae7688.eps'... Layout output to `lily-0dae7688-1.eps'... Layout output to `lily-0dae7688-2.eps'... Layout output to `lily-0dae7688-3.eps'... Layout output to `lily-0dae7688-4.eps'... Converting to `./lily-0dae7688-1.pdf'... Converting to `./lily-0dae7688-2.pdf'... Converting to `./lily-0dae7688-3.pdf'... Converting to `./lily-0dae7688-4.pdf'... Writing lily-0dae7688-systems.texi... Writing lily-0dae7688-systems.tex... Writing lily-0dae7688-systems.count... Success: compilation successfully completed The PDFs displayed musical staves in okular. $ grep glib lilypond.trace openat(AT_FDCWD, "/lib64/libglib-2.0.so.0", O_RDONLY|O_CLOEXEC) = 3 That should be enough for glib2. Not messing with mingw - Windows is not welcome in this establishment. The mingw packages updated OK.
CC: (none) => tarazed25Whiteboard: (none) => MGA8-64-OK
Sigh. It would be nice if I could dump Windows, too - but a couple of necessary tasks demand it. Fortunately, I can confine it to VirtualBox... But I digress. A massive and extensive test, Len. Your efforts are appreciated. Validating. Advisory in Comment 10.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
Advisory committed to SVN.
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0123.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
Two CVEs for this update (CVE-2021-27218, CVE-2021-27219): https://ubuntu.com/security/notices/USN-4759-1
Summary: glib2.0 new security issues fixed upstream in 2.66.6 => glib2.0 new security issues fixed upstream in 2.66.6 (including CVE-2021-2721[89])