mga7, x86_64

Before updating installed the listed packages release versions.

CVE-2020-10029
https://sourceware.org/bugzilla/show_bug.cgi?id=25487

Copied the C snippet and compiled it.

$ gcc poc_sinl_buffer_overflow.c -lm -o poc1
$ ./poc1
Segmentation fault (core dumped)

Upstream detected stack smashing.

glob use-after-free:
https://sourceware.org/bugzilla/show_bug.cgi?id=25414
https://lists.gnu.org/r/bug-gnulib/2020-01/msg00102.html
Downloaded the PoC C script and tried to compile it:
$ export CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address -fsanitize-address-use-after-scope"
$ gcc $CFLAGS -I. -Ilib glob_crash2.c -o glob_crash2 lib/.libs/libgnu.a
gcc: error: lib/.libs/libgnu.a: No such file or directory
Another approach:
$ gcc $CFLAGS glob_crash2.c -o glob_crash2/usr/bin/ld: cannot find libasan_preinit.o: No such file or directory
/usr/bin/ld: cannot find -lasan
collect2: error: ld returned 1 exit status
locate returns:
/usr/lib64/libasan.so.5
/usr/lib64/libasan.so.5.0.0
/usr/lib64/libasan_preinit.o

Skipping the second test, and waiting for the mirrors to sync.

CC: (none) => tarazed25

Continuing from comment 1:
Updated the packages.

CVE-2020-10029
$ gcc poc_sinl_buffer_overflow.c -lm -o poc1
$ ./poc1

Good result.

glob use-after-free:
$ export CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address -fsanitize-address-use-after-scope"
$ gcc $CFLAGS glob_crash2.c -o glob_crash2
$ ./glob_crash2

No problem there, although the test is not identical to the upstream one.  This compilation succeeded on a partition where asan had worked before, in a gcc test.  gcc was already updated and glibc had been partially updated by accident, which was the reason for switching to a partition without the upgrades (to perform the PoC).

Not much idea how to test glibc but referring to a previous bug (#23136) compiled memorex.c from the man page and ran it.$ cat memorex.c
#include <stdio.h>
#include <stdlib.h>
#define CYCLES 20
int main(int argc, char *argv[])
{
   int i, j;
   int *p;

   printf("malloc: %zd\n", sizeof(int) * 100);
   p = malloc(sizeof(int) * 100);
   for (i = 0; i < CYCLES; i++) {
      if (i < CYCLES / 2)
         j = i;
      else
         j--;
      printf("realloc: %zd\n", sizeof(int) * (j * 50 + 110));
      p = realloc(p, sizeof(int) * (j * 50 + 100));
      printf("realloc: %zd\n", sizeof(int) * ((j+1) * 150 + 110));
      p = realloc(p, sizeof(int) * ((j + 1) * 150 + 110));
   }
   free(p);
   exit(EXIT_SUCCESS);
}

$ ./memorex
malloc: 400
realloc: 440
realloc: 1040
realloc: 640
realloc: 1640
....
realloc: 440
realloc: 1040
realloc: 240
realloc: 440

Another snippet:
--------------------------------
// test-posix-memalign.c
#include <stdlib.h>
#include <stdint.h>

int main( int argc, char **argv )
{
	void *p;
 	return posix_memalign( &p, 0x10, SIZE_MAX - 0x20 );
}
--------------------------------
$ mtrace test-posix-memalign
No memory leaks.

There were many references to glibc in a previous local build of celestia so I cleaned up the directories and started from scratch.
$ mgarepo co -d 7 celestia
$ cd celestia
$ bm -ls
$ bm -l

which finished successfully.
$ ls
BUILD/  BUILDROOT/  RPMS/  SOURCES/  SPECS/  SRPMS/
$ du -hs .
2.9G	.

That will have to do.

Whiteboard: (none) => MGA7-64-OK

The glibc runtime libraries are so fundamental to the operation of the distro that it seemed only proper to try 32-bit hardware to look for regressions. To that end, I tried this on a Dell Inspiron 5100, 32-bit P4, 2GB RAM, Radeon RV200 graphics, old Atheros wifi, running a 32-bit Xfce system.

Using urpmq --whatrequires glibc produces an exceptionally long list - I think asking what doesn't require it would be considerably shorter. But, I did note that several xfce packages do require it, so I would think that the DE running at all would be an adequate test.

The glibc package installed cleanly, and advised a reboot. Rebooted to a working desktop, tried some apps, everything appeared to be working as it should. I'm going to say this is OK for 32-bits.

Validating.

Whiteboard: MGA7-64-OK => MGA7-64-OK MGA7-32-OK
CC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => validated_update

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2020-0135.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED

*** Bug 26407 has been marked as a duplicate of this bug. ***

CC: (none) => luigiwalser

This update also fixed CVE-2020-1752.