Cauldron patched.

Packages for mga4:

SRPMS:
glibc-2.18-9.8.mga4.src.rpm


i586:
glibc-2.18-9.8.mga4.i586.rpm
glibc-devel-2.18-9.8.mga4.i586.rpm
glibc-doc-2.18-9.8.mga4.noarch.rpm
glibc-i18ndata-2.18-9.8.mga4.i586.rpm
glibc-profile-2.18-9.8.mga4.i586.rpm
glibc-static-devel-2.18-9.8.mga4.i586.rpm
glibc-utils-2.18-9.8.mga4.i586.rpm
nscd-2.18-9.8.mga4.i586.rpm


x86_64:
glibc-2.18-9.8.mga4.x86_64.rpm
glibc-devel-2.18-9.8.mga4.x86_64.rpm
glibc-doc-2.18-9.8.mga4.noarch.rpm
glibc-i18ndata-2.18-9.8.mga4.x86_64.rpm
glibc-profile-2.18-9.8.mga4.x86_64.rpm
glibc-static-devel-2.18-9.8.mga4.x86_64.rpm
glibc-utils-2.18-9.8.mga4.x86_64.rpm
nscd-2.18-9.8.mga4.x86_64.rpm



Advisory:
The vfprintf function in stdio-common/vfprintf.c in GNU C Library (aka glibc)
2.5, 2.12, and probably other versions does not "properly restrict the use of"
the alloca function when allocating the SPECS array, which allows context-
dependent attackers to bypass the FORTIFY_SOURCE format-string protection
mechanism and cause a denial of service (crash) or possibly execute arbitrary
code via a crafted format string using positional parameters and a large
number of format specifiers (CVE-2012-3406).

The nss_dns implementation of getnetbyname could run into an infinite loop
if the DNS response contained a PTR record of an unexpected format
(CVE-2014-9402).

Also glibc lock elision (new feature in glibc 2.18) has been disabled
as it can break glibc at runtime on newer Intel hardware (due to hardware
bug)

Assignee: tmb => qa-bugs
Whiteboard: MGA4TOO => (none)
Version: Cauldron => 4

The patch for CVE-2012-3406 contains testcases, but they don't build.

CVE-2014-9402 has a PoC here:
https://sourceware.org/bugzilla/show_bug.cgi?id=17630#c10

but that one always tells me the lookup failed (before or after the update).  I'm not sure why.

I have the update installed on my newer PogoLinux system at home on Mageia 4 i586 and don't notice any general problems.

MGA4-64 on HP Probook 6555b KDE
No installation issues.
I copied the PoC program from Comment 2 in a file, but when I try to compile it I get error
$ gcc glibcbug.c 
glibcbug.c: In function âmainâ:
glibcbug.c:15:5: error: âforâ loop initial declarations are only allowed in C99 mode
     for (char **p = ne->n_aliases; *p; ++p) {
     ^
glibcbug.c:15:5: note: use option -std=c99 or -std=gnu99 to compile your code

CC: (none) => herman.viaene

(In reply to Herman Viaene from comment #3)
> MGA4-64 on HP Probook 6555b KDE
> No installation issues.
> I copied the PoC program from Comment 2 in a file, but when I try to compile
> it I get error
> $ gcc glibcbug.c 
> glibcbug.c: In function âmainâ:
> glibcbug.c:15:5: error: âforâ loop initial declarations are only allowed in
> C99 mode
>      for (char **p = ne->n_aliases; *p; ++p) {
>      ^
> glibcbug.c:15:5: note: use option -std=c99 or -std=gnu99 to compile your code

It tells you in the last line of output how to fix that.  gcc -std=c99 glibcbug.c

MGA4-64 on HP Probook 6555b KDE
At CLI:
$ gcc -std=c99 glibcbug.c -o glbc
[xxx@yyy ~]$ ./glbc 
Segmentation fault

This version of glibc does not cause the 5 minute delay on my system, that the
prior updates testing version did, so it's ok by me, though more people should
test it before oking it.

CC: (none) => davidwhodgins

(In reply to Dave Hodgins from comment #6)
> This version of glibc does not cause the 5 minute delay on my system, that
> the
> prior updates testing version did, 

I wonder if that actually was an glibc issue, or if you happend to install the dbus package with low timeouts we had in testing so people could confirm the timing issues and grab more verbose logs for Simon McVittie (upstream maintainer) as tracked on: https://bugs.mageia.org/show_bug.cgi?id=14249

MGA4 x64 real hardware

Can someone please explain the last part of: ânetworks: files dnsâ in
 /etc/nsswitch.conf
using the name â4.0.41.198.in-addr.arpa.â given in the PoC from Comment 2? i.e. Where to cite the given name string. That file currently has a
 networks:       files
line, OK one adds 'dns'. But the other goes where?
[Meanwhile, I got the same result as Herman in Comment 5].

CC: (none) => lewyssmith

(In reply to Lewis Smith from comment #8)
> MGA4 x64 real hardware
> 
> Can someone please explain the last part of: ânetworks: files dnsâ in
>  /etc/nsswitch.conf
> using the name â4.0.41.198.in-addr.arpa.â given in the PoC from Comment 2?
> i.e. Where to cite the given name string. That file currently has a
>  networks:       files
> line, OK one adds 'dns'. But the other goes where?
> [Meanwhile, I got the same result as Herman in Comment 5].

Ahh, I hadn't edited my nsswitch.conf, so maybe that's why I couldn't get the PoC to work.  Anyway, the 4.0.41.198.in-addr.arpa. is supposed to be given as an argument to the PoC program when you run it.

CC: (none) => luigiwalser

(In reply to Thomas Backlund from comment #7)
> (In reply to Dave Hodgins from comment #6)
> > This version of glibc does not cause the 5 minute delay on my system, that
> > the
> > prior updates testing version did, 
> 
> I wonder if that actually was an glibc issue, or if you happend to install
> the dbus package with low timeouts we had in testing so people could confirm
> the timing issues and grab more verbose logs for Simon McVittie (upstream
> maintainer) as tracked on: https://bugs.mageia.org/show_bug.cgi?id=14249

Downgrading just glibc fixed the problem, so I'm assuming
it was a glibc issue.

Ideally this would have gone out with the kernel update we just pushed.  I think it has been long enough to OK and validate this one.

glibc, kernel and nvidia drivers at one time is likely asking for trouble. We'll try and get more testers for this in Thursday meeting.

It's better to push glibc and kernel at the same time, so people installing updates only have to reboot once.  We've done it this way more often than not.

Not with updated nvidia driver at the same time. It would cause a large surface area for breakage with mirror syncs etc.

I don't see the relevance of the nvidia driver.  I'd prefer to avoid the inconvenience for the users/sysadmins out there.

We're clearly viewing this from different angles. Let's ask Thomas.

What would you prefer Thomas? I'll upload the advisory so it can be validated if you give the OK.

Advisory uploaded.

Whiteboard: (none) => has_procedure advisory

MGA4 x64
At last re-doing the PoC test left at Comment 8 & Comment 9.
 glibc-2.18-9.8.mga4
 glibc-devel-2.18-9.8.mga4
i.e. only after the update, which I have been using without problems for some time.

 $ ./a.out 4.0.41.198.in-addr.arpa.
 a.out: getnetbyname(4.0.41.198.in-addr.arpa.) failed
I suppose this is correct; at least there is no loop (the bug, Comment 1) nor segfault (Comment 5).

Comment 11 - Comment 15 seem sensible: yes, push glibc with the kernels, and nvidia is not relevant here so should not be linked.

Lewis,
What did you change since Comment 8? Ik keep getting the segmentation fault.

Misread the PoC, I get the same result as Comment 18

MGA4-32 on AcerD620 Xfce
No installation issues. Confirm result as per Comment 18.

Whiteboard: has_procedure advisory => advisory has_procedure MGA4-64-OK MGA4-32-OK

Validating.

Please push to 4 updates

Thanks

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

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

http://advisories.mageia.org/MGASA-2015-0013.html

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