Bug 11059 - glibc new security issues CVE-2012-4412 CVE-2012-4424 CVE-2013-2207 CVE-2013-4237 CVE-2013-4332 CVE-2013-4458 CVE-2013-4788
: glibc new security issues CVE-2012-4412 CVE-2012-4424 CVE-2013-2207 CVE-2013-...
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 3
: All Linux
: Normal Severity: major
: ---
Assigned To: QA Team
: Sec team
: http://lwn.net/Vulnerabilities/564410/
: MGA2TOO advisory mga2-32-ok MGA2-64-O...
: validated_update
: 11463 11468
: 11223
  Show dependency treegraph
 
Reported: 2013-08-22 19:18 CEST by David Walser
Modified: 2013-11-22 20:22 CET (History)
9 users (show)

See Also:
Source RPM: glibc
CVE:


Attachments
Source code from poc (552 bytes, text/plain)
2013-10-22 22:04 CEST, Dave Hodgins
Details

Description David Walser 2013-08-22 19:18:24 CEST
Fedora has issued an advisory on August 20:
https://lists.fedoraproject.org/pipermail/package-announce/2013-August/114498.html

Mageia 2 and Mageia 3 are also affected.

I looks like CVE-2013-2207 and CVE-2013-4237 may not affect Mageia 2.

Reproducible: 

Steps to Reproduce:
Comment 1 Thomas Backlund 2013-08-22 19:43:30 CEST
Already on my TODO as I've been working on the cauldron glibc-2.18 that closes some of them but also needs patching for others..
Comment 2 David Walser 2013-09-13 16:24:37 CEST
There's also CVE-2013-4332 in Bug 11223.
Comment 3 Thomas Backlund 2013-09-17 11:25:29 CEST
Cauldron glibc-2.18 pushed to /release
Comment 4 David Walser 2013-09-30 19:51:42 CEST
There's also CVE-2013-4788, which has also been fixed now by Fedora (along with CVE-2013-4332):
https://lists.fedoraproject.org/pipermail/package-announce/2013-September/117177.html

from http://lwn.net/Vulnerabilities/568929/
Comment 5 Thomas Backlund 2013-10-06 21:10:38 CEST
Finally got around to fix them all ...

Cauldron is fixed as of glibc-2.18-3.mga4

For mga2 and mga3 this is done:

Fixes:
- initialize the pointer guard used for pointer mangling (CVE-2013-4788)
- fix Three integer overflows in glibc memory allocator (CVE-2013-4332)
- fix Buffer overwrite when using readdir_r on file systems returning
  file names longer than NAME_MAX characters (CVE-2013-4237)
- fix Improper pseudotty ownership and permissions changes when granting
  access to the slave pseudoterminal, by removing pt_chown (CVE-2013-2207)
  (this may break chroots if their devpts was not mounted correctly.
   make sure to mount the devpts correctly with gid=5)
- fix strcoll() integer overflow leading to buffer overflow (CVE-2012-4412)
- fix alloca() stack overflow in the strcoll() interface (CVE-2012-4424)
- fix typo in nscd.service
- Correct the processing of '\x80' characters in crypt_freesec.c
- drop minimal required kernel to 2.6.32 so it works in chroots on top
  of enterprise kernels


Mageia 2:
SRPMS:
glibc-2.14.1-11.mga2.src.rpm

i586:
glibc-2.14.1-11.mga2.i586.rpm
glibc-devel-2.14.1-11.mga2.i586.rpm
glibc-doc-2.14.1-11.mga2.noarch.rpm
glibc-doc-pdf-2.14.1-11.mga2.noarch.rpm
glibc-i18ndata-2.14.1-11.mga2.i586.rpm
glibc-profile-2.14.1-11.mga2.i586.rpm
glibc-static-devel-2.14.1-11.mga2.i586.rpm
glibc-utils-2.14.1-11.mga2.i586.rpm
nscd-2.14.1-11.mga2.i586.rpm

x86_64:
glibc-2.14.1-11.mga2.x86_64.rpm
glibc-devel-2.14.1-11.mga2.x86_64.rpm
glibc-doc-2.14.1-11.mga2.noarch.rpm
glibc-doc-pdf-2.14.1-11.mga2.noarch.rpm
glibc-i18ndata-2.14.1-11.mga2.x86_64.rpm
glibc-profile-2.14.1-11.mga2.x86_64.rpm
glibc-static-devel-2.14.1-11.mga2.x86_64.rpm
glibc-utils-2.14.1-11.mga2.x86_64.rpm
nscd-2.14.1-11.mga2.x86_64.rpm



Mageia 3:
SRPMS:
glibc-2.17-7.mga3.src.rpm

i586:
glibc-2.17-7.mga3.i586.rpm
glibc-devel-2.17-7.mga3.i586.rpm
glibc-doc-2.17-7.mga3.noarch.rpm
glibc-i18ndata-2.17-7.mga3.i586.rpm
glibc-profile-2.17-7.mga3.i586.rpm
glibc-static-devel-2.17-7.mga3.i586.rpm
glibc-utils-2.17-7.mga3.i586.rpm
nscd-2.17-7.mga3.i586.rpm

x86_64:
glibc-2.17-7.mga3.x86_64.rpm
glibc-devel-2.17-7.mga3.x86_64.rpm
glibc-doc-2.17-7.mga3.noarch.rpm
glibc-i18ndata-2.17-7.mga3.x86_64.rpm
glibc-profile-2.17-7.mga3.x86_64.rpm
glibc-static-devel-2.17-7.mga3.x86_64.rpm
glibc-utils-2.17-7.mga3.x86_64.rpm
nscd-2.17-7.mga3.x86_64.rpm
Comment 6 Thomas Backlund 2013-10-06 21:11:49 CEST
*** Bug 11223 has been marked as a duplicate of this bug. ***
Comment 7 Oden Eriksson 2013-10-07 09:49:42 CEST
Why don't you use subrel here?
Comment 8 Thomas Backlund 2013-10-07 10:28:11 CEST
Because its not required...

The upgrade path is ensured with version changes: mga2: 2.14.1 -> mga3: 2.17 -> mga4: 2.18
Comment 9 Samuel Verschelde 2013-10-07 10:34:58 CEST
Well, updates policy says "If the version didn't change, leave mkrel as is and '%define subrel 1'" :)
Comment 11 William Kenney 2013-10-07 16:55:23 CEST
In VirtualBox, M3, KDE, 32-bit

Package(s) under test:
glibc


Default package installed:
[root@localhost wilcal]# urpmi glibc
Package glibc-2.17-5.mga3.i586 is already installed
KDE system operating normally.

Install glibc updates from core updates_testing:

[root@localhost wilcal]# urpmi glibc
Package glibc-2.17-7.mga3.i586 is already installed
Successfuly reboot system back to working KDE desktop.

Would this be a good enough test for this?


Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
VirtualBox 4.2.16-1.mga3.x86_64.rpm
Comment 12 William Kenney 2013-10-07 17:10:12 CEST
In VirtualBox, M3, KDE, 64-bit

Package(s) under test:
glibc


Default package installed:
[root@localhost wilcal]# urpmi glibc
Package glibc-2.17-5.mga3.x86_64 is already installed
KDE system operating normally.

Install glibc updates from core updates_testing:

[root@localhost wilcal]# urpmi glibc
Package glibc-2.17-7.mga3.x86_64 is already installed
Successfuly reboot system back to working KDE desktop.

Would this be a good enough test for this?


Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
VirtualBox 4.2.16-1.mga3.x86_64.rpm
Comment 13 William Kenney 2013-10-07 17:30:16 CEST
In VirtualBox, M2, KDE, 32-bit

Package(s) under test:
glibc


Default package installed:
[root@localhost wilcal]# urpmi glibc
Package glibc-2.14.1-10.mga2.i586 is already installed
KDE system operating normally.

Install glibc updates from core updates_testing:

[root@localhost wilcal]# urpmi glibc
Package glibc-2.14.1-11.mga2.i586 is already installed
Successfuly reboot system back to working KDE desktop.

Would this be a good enough test for this?


Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
VirtualBox 4.2.16-1.mga3.x86_64.rpm
Comment 14 William Kenney 2013-10-07 17:44:39 CEST
In VirtualBox, M2, KDE, 64-bit

Package(s) under test:
glibc


Default package installed:
[root@localhost wilcal]# urpmi glibc
Package glibc-2.14.1-10.mga2.x86_64 is already installed
KDE system operating normally.

Install glibc updates from core updates_testing:

[root@localhost wilcal]# urpmi glibc
Package glibc-2.14.1-11.mga2.x86_64 is already installed
Successfuly reboot system back to working KDE desktop.

Would this be a good enough test for this?


Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
VirtualBox 4.2.16-1.mga3.x86_64.rpm
Comment 15 Thomas Backlund 2013-10-07 17:55:02 CEST
(In reply to Samuel VERSCHELDE from comment #9)
> Well, updates policy says "If the version didn't change, leave mkrel as is
> and '%define subrel 1'" :)


Hm, I seem to remember us discussing changing that to only ensure upgrade path at some time, but maybe we never finished that debate ...

Anyway, In this case I wont remove the rpms from updates_testing and redo with lower rel + subrel as I've already installed it on some live servers to get a wider test base, and I know several OpenVZ users already using them in order to be able to run mga in VZ containers (they need the "drop minimal required kernel to 2.6.32")


(In reply to William Kenney from comment #12)

> Would this be a good enough test for this?

For example his fix: "removing pt_chown (CVE-2013-2207)"

check that terminals like xfce-terminal still works

other than that I think multiple testers and some days of testing before validating is good.
Comment 16 Dave Hodgins 2013-10-07 18:35:35 CEST
(In reply to William Kenney from comment #12)
> In VirtualBox, M3, KDE, 64-bit
> Package(s) under test:
> glibc

> Would this be a good enough test for this?

glibc is a low enough level package, it should be
tested on multiple systems, on real hardware, as
well as in virtualbox.

I'll be testing later today on my system, and
as there is a poc (which I haven't looked at yet),
we should try and recreate the problem before
and after installing the update, to ensure the
specific problems are actually fixed.
Comment 17 William Kenney 2013-10-07 21:07:40 CEST
I took out my OK stuff for now.
These are security issues and I'm not sure we
can reproduce those. I agree with you on the
multiple platforms.
Comment 18 Lewis Smith 2013-10-09 20:16:22 CEST
I have installed this *glibc-2.17-7.mga3 only*. The re-started system basically works, but 
"check that terminals like xfce-terminal still works"
LX terminal (under LXDE) behaves strangely. Switchiing to it with Alt/Tab once gave me a same-size Mageia window, but I recovered the proper window by other means.
Doing likewise now displays the terminal window with the cursor in mid air. a few lines down from a prompt, which itself comes after a command several ago, intermediate commands having disappeared. Up-arrow shows them in space where the cursor is.
ALAS, I did not try this before updating glibc... Should I/can I revert glibc?
Comment 19 Oden Eriksson 2013-10-10 07:47:59 CEST
======================================================
Name: CVE-2012-4412
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4412
Final-Decision: 
Interim-Decision: 
Modified: 
Proposed: 
Assigned: 20120821
Category: 
Reference: MLIST:[oss-security] 20130907 CVE Request -- glibc: strcoll() integer overflow leading to buffer  overflow + another alloca() stack overflow issue (upstream #14547 &&  #14552)
Reference: URL:http://www.openwall.com/lists/oss-security/2012/09/07/9
Reference: CONFIRM:http://sourceware.org/bugzilla/show_bug.cgi?id=14547
Reference: CONFIRM:https://bugzilla.redhat.com/show_bug.cgi?id=855385

Integer overflow in string/strcoll_l.c in the GNU C Library (aka glibc
or libc6) 2.17 and earlier allows context-dependent attackers to cause
a denial of service (crash) or possibly execute arbitrary code via a
long string, which triggers a heap-based buffer overflow.



======================================================
Name: CVE-2012-4424
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4424
Final-Decision: 
Interim-Decision: 
Modified: 
Proposed: 
Assigned: 20120821
Category: 
Reference: MLIST:[oss-security] 20130913 CVE Request -- glibc: strcoll() integer overflow leading to buffer  overflow + another alloca() stack overflow issue (upstream #14547 &&  #14552)
Reference: URL:http://www.openwall.com/lists/oss-security/2012/09/13/16
Reference: CONFIRM:http://sourceware.org/bugzilla/show_bug.cgi?id=14547
Reference: CONFIRM:https://bugzilla.redhat.com/show_bug.cgi?id=858238

Stack-based buffer overflow in string/strcoll_l.c in the GNU C Library
(aka glibc or libc6) 2.17 and earlier allows context-dependent
attackers to cause a denial of service (crash) or possibly execute
arbitrary code via a long string that triggers a malloc failure and
use of the alloca function.



======================================================
Name: CVE-2013-2207
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2207
Final-Decision: 
Interim-Decision: 
Modified: 
Proposed: 
Assigned: 20130219
Category: 
Reference: MLIST:[libc-alpha] 20130812 The GNU C Library version 2.18 is now available
Reference: URL:https://sourceware.org/ml/libc-alpha/2013-08/msg00160.html
Reference: CONFIRM:https://bugzilla.redhat.com/show_bug.cgi?id=976408
Reference: CONFIRM:https://sourceware.org/bugzilla/show_bug.cgi?id=15755

pt_chown in GNU C Library (aka glibc or libc6) before 2.18 does not
properly check permissions for tty files, which allows local users to
change the permission on the files and obtain access to arbitrary
pseudo-terminals by leveraging a FUSE file system.



======================================================
Name: CVE-2013-4237
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4237
Final-Decision: 
Interim-Decision: 
Modified: 
Proposed: 
Assigned: 20130612
Category: 
Reference: MLIST:[oss-security] 20130812 Re: CVE Request -- glibc: Buffer overwrite when using  readdir_r on file systems returning file names longer than NAME_MAX characters
Reference: URL:http://www.openwall.com/lists/oss-security/2013/08/12/8
Reference: CONFIRM:https://bugzilla.redhat.com/show_bug.cgi?id=995839
Reference: CONFIRM:https://sourceware.org/bugzilla/show_bug.cgi?id=14699
Reference: CONFIRM:https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=91ce40854d0b7f865cf5024ef95a8026b76096f3

sysdeps/posix/readdir_r.c in the GNU C Library (aka glibc or libc6)
2.18 and earlier allows context-dependent attackers to cause a denial
of service (out-of-bounds write and crash) or possibly execute
arbitrary code via a crafted (1) NTFS or (2) CIFS image.



======================================================
Name: CVE-2013-4332
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4332
Final-Decision: 
Interim-Decision: 
Modified: 
Proposed: 
Assigned: 20130612
Category: 
Reference: MLIST:[oss-security] 20130912 Re: CVE Request: Three integer overflows in glibc memory allocator
Reference: URL:http://www.openwall.com/lists/oss-security/2013/09/12/6
Reference: CONFIRM:https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-4332
Reference: CONFIRM:https://sourceware.org/bugzilla/show_bug.cgi?id=15855
Reference: CONFIRM:https://sourceware.org/bugzilla/show_bug.cgi?id=15856
Reference: CONFIRM:https://sourceware.org/bugzilla/show_bug.cgi?id=15857

Multiple integer overflows in malloc/malloc.c in the GNU C Library
(aka glibc or libc6) 2.18 and earlier allow context-dependent
attackers to cause a denial of service (heap corruption) via a large
value to the (1) pvalloc, (2) valloc, (3) posix_memalign, (4)
memalign, or (5) aligned_alloc functions.
Comment 20 Dave Hodgins 2013-10-10 20:42:48 CEST
Advisory 11059.adv committed to svn
Comment 21 Thomas Backlund 2013-10-11 11:21:59 CEST
Just a note, I'm doing a rebuild of theese for a dirent alignment breakage introduced by:

CVE-2013-4237, BZ #14699: Buffer overflow in readdir_r


The breakage was reported against 32bit sparc so far, but to be safe side and stay in sync with upstream I will merge the fix
Comment 22 Thomas Backlund 2013-10-11 17:55:54 CEST
Fixed rpms ( now with subrel :) ):

Mageia 2:
SRPM:
glibc-2.14.1-11.1.mga2.src.rpm

i586:
glibc-2.14.1-11.1.mga2.i586.rpm
glibc-devel-2.14.1-11.1.mga2.i586.rpm
glibc-doc-2.14.1-11.1.mga2.noarch.rpm
glibc-doc-pdf-2.14.1-11.1.mga2.noarch.rpm
glibc-i18ndata-2.14.1-11.1.mga2.i586.rpm
glibc-profile-2.14.1-11.1.mga2.i586.rpm
glibc-static-devel-2.14.1-11.1.mga2.i586.rpm
glibc-utils-2.14.1-11.1.mga2.i586.rpm
nscd-2.14.1-11.1.mga2.i586.rpm

x86_64:
glibc-2.14.1-11.1.mga2.x86_64.rpm
glibc-devel-2.14.1-11.1.mga2.x86_64.rpm
glibc-doc-2.14.1-11.1.mga2.noarch.rpm
glibc-doc-pdf-2.14.1-11.1.mga2.noarch.rpm
glibc-i18ndata-2.14.1-11.1.mga2.x86_64.rpm
glibc-profile-2.14.1-11.1.mga2.x86_64.rpm
glibc-static-devel-2.14.1-11.1.mga2.x86_64.rpm
glibc-utils-2.14.1-11.1.mga2.x86_64.rpm
nscd-2.14.1-11.1.mga2.x86_64.rpm


Mageia 3:
SRPM:
glibc-2.17-7.1.mga3.src.rpm

i586:
glibc-2.17-7.1.mga3.i586.rpm
glibc-devel-2.17-7.1.mga3.i586.rpm
glibc-doc-2.17-7.1.mga3.noarch.rpm
glibc-i18ndata-2.17-7.1.mga3.i586.rpm
glibc-profile-2.17-7.1.mga3.i586.rpm
glibc-static-devel-2.17-7.1.mga3.i586.rpm
glibc-utils-2.17-7.1.mga3.i586.rpm
nscd-2.17-7.1.mga3.i586.rpm

x86_64:
glibc-2.17-7.1.mga3.x86_64.rpm
glibc-devel-2.17-7.1.mga3.x86_64.rpm
glibc-doc-2.17-7.1.mga3.noarch.rpm
glibc-i18ndata-2.17-7.1.mga3.x86_64.rpm
glibc-profile-2.17-7.1.mga3.x86_64.rpm
glibc-static-devel-2.17-7.1.mga3.x86_64.rpm
glibc-utils-2.17-7.1.mga3.x86_64.rpm
nscd-2.17-7.1.mga3.x86_64.rpm


Advisory updated for new versions...
Comment 23 Dave Hodgins 2013-10-14 23:31:38 CEST
As discussed with tmb on irc, I'll be testing the pocs shortly, but the
release of glibc will be held until the kernel update is also ready.
Comment 24 Bill Wilkinson 2013-10-15 16:15:59 CEST
Tested x86_64, general use OK.

Compaq presario laptop:
ssb             : Broadcom Corporation|BCM4311 802.11a/b/g [NETWORK_OTHER] (vendor:14e4 device:4312 subv:103c subd:1360) (rev: 01)
Card:NVIDIA GeForce 6100 to GeForce 7950: NVIDIA Corporation|C51 [GeForce Go 6150] [DISPLAY_VGA] (vendor:10de device:0244 subv:103c subd:30b7) (rev: a2)
Dual-core Turion  processor
Did not test PoCs.
Comment 25 Bill Wilkinson 2013-10-15 17:53:39 CEST
Tested under mga3-32, general use OK

Did not test PoCs

Card:NVIDIA GeForce 6100 to GeForce 7950: NVIDIA Corporation|NV44A [GeForce 6200] [DISPLAY_VGA] (vendor:10de device:0221 subv:196e subd:02f3) (rev: a1)

Sempron 3000+ processor.
Comment 26 William Kenney 2013-10-15 19:11:31 CEST
I'm struggling to get M3 updates under test working in Vbox glibc + kernel-desktop
I donna if it's me or there's something wrong. I install updates and it boots
to a blank black screen. More testing here today.
Comment 27 William Kenney 2013-10-15 19:55:05 CEST
In VirtualBox, M2, KDE, 32-bit

[root@localhost wilcal]# uname -a
Linux localhost 3.4.52-desktop-1.mga2 #1 SMP Thu Jul 4 07:31:09 UTC 2013 i686 i686 i386 GNU/Linux
[root@localhost wilcal]# urpmi vboxadditions-kernel-desktop-latest
Package vboxadditions-kernel-desktop-latest-4.2.16-1.mga2.i586 is already installed
Marking vboxadditions-kernel-desktop-latest as manually installed, it won't be auto-orphaned
writing /var/lib/rpm/installed-through-deps.list
[root@localhost wilcal]# urpmi glibc
Package glibc-2.14.1-10.mga2.i586 is already installed

Install glibc & kernel-desktop-latest updates from core updates_testing:

reboot system

[root@localhost wilcal]# uname -a
Linux localhost 3.4.66-desktop-1.mga2 #1 SMP Mon Oct 14 19:38:51 UTC 2013 i686 i686 i386 GNU/Linux
[root@localhost wilcal]# urpmi vboxadditions-kernel-desktop-latest
Package vboxadditions-kernel-desktop-latest-4.2.16-3.mga2.i586 is already installed
[root@localhost wilcal]# urpmi glibc
Package glibc-2.14.1-11.1.mga2.i586 is already installed

seems like it has come back just fine.
Comment 28 William Kenney 2013-10-15 20:31:24 CEST
In VirtualBox, M2, KDE, 64-bit

[root@localhost wilcal]# uname -a
Linux localhost 3.4.52-desktop-1.mga2 #1 SMP Thu Jul 4 07:23:54 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi vboxadditions-kernel-desktop-latest
Package vboxadditions-kernel-desktop-latest-4.2.16-1.mga2.x86_64 is already installed
Marking vboxadditions-kernel-desktop-latest as manually installed, it won't be auto-orphaned
writing /var/lib/rpm/installed-through-deps.list
[root@localhost wilcal]# urpmi glibc
Package glibc-2.14.1-10.mga2.x86_64 is already installed

Install glibc & kernel-desktop-latest updates from core updates_testing:

reboot system

[root@localhost wilcal]# uname -a
Linux localhost 3.4.66-desktop-1.mga2 #1 SMP Mon Oct 14 19:37:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi vboxadditions-kernel-desktop-latest
Package vboxadditions-kernel-desktop-latest-4.2.16-3.mga2.x86_64 is already installed
[root@localhost wilcal]# urpmi glibc
Package glibc-2.14.1-11.1.mga2.x86_64 is already installed

seems like it has come back just fine.

Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
VirtualBox 4.2.16-1.mga3.x86_64.rpm
Comment 29 William Kenney 2013-10-15 21:45:25 CEST
In VirtualBox, M3, KDE, 32-bit

[root@localhost wilcal]# uname -a
Linux localhost 3.8.13.4-desktop-1.mga3 #1 SMP Thu Jul 4 14:04:55 UTC 2013 i686 i686 i686 GNU/Linux
[root@localhost wilcal]# urpmi vboxadditions-kernel-desktop-latest
Package vboxadditions-kernel-desktop-latest-4.2.16-1.mga3.i586 is already installed
Marking vboxadditions-kernel-desktop-latest as manually installed, it won't be auto-orphaned
writing /var/lib/rpm/installed-through-deps.list
[root@localhost wilcal]# urpmi glibc
Package glibc-2.17-5.mga3.i586 is already installed

Install glibc & kernel-desktop-latest updates from core updates_testing:

reboot system
Fails to come back to a working desktop. Leaves you in a blank screen.

Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
VirtualBox 4.2.16-1.mga3.x86_64.rpm
Comment 30 William Kenney 2013-10-15 22:25:07 CEST
In VirtualBox, M3, KDE, 64-bit

[root@localhost wilcal]# uname -a
Linux localhost 3.8.13.4-desktop-1.mga3 #1 SMP Thu Jul 4 13:56:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi vboxadditions-kernel-desktop-latest
Package vboxadditions-kernel-desktop-latest-4.2.16-1.mga3.x86_64 is already installed
Marking vboxadditions-kernel-desktop-latest as manually installed, it won't be auto-orphaned
writing /var/lib/rpm/installed-through-deps.list
[root@localhost wilcal]# urpmi glibc
Package glibc-2.17-5.mga3.x86_64 is already installed

Install glibc & kernel-desktop-latest updates from core updates_testing:

reboot system

[root@localhost wilcal]# uname -a
Linux localhost 3.10.16-desktop-1.mga3 #1 SMP Mon Oct 14 17:29:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi vboxadditions-kernel-desktop-latest
Package vboxadditions-kernel-desktop-latest-4.2.18-3.mga3.x86_64 is already installed
[root@localhost wilcal]# urpmi glibc
Package glibc-2.17-7.1.mga3.x86_64 is already installed

seems like it has come back just fine.

Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
VirtualBox 4.2.16-1.mga3.x86_64.rpm
Comment 31 William Kenney 2013-10-15 22:28:44 CEST
In VirtualBox, M3, KDE, 32-bit

Refer to my Comment 29
If I interrupt the boot process and select the old kernel ( 3.8.13.4-desktop-1.mga3 ) it boots to a working desktop just fine.
Comment 32 William Kenney 2013-10-16 00:25:24 CEST
On real hardware, M3, KDE, 32-bit

[root@localhost wilcal]# uname -a
Linux localhost 3.8.13.4-desktop-1.mga3 #1 SMP Thu Jul 4 14:04:55 UTC 2013 i686 i686 i686 GNU/Linux
[root@localhost wilcal]# urpmi glibc
Package glibc-2.17-5.mga3.i586 is already installed

Install glibc & kernel-desktop-latest updates from core updates_testing:

[root@localhost wilcal]# uname -a
Linux localhost 3.10.16-desktop-1.mga3 #1 SMP Mon Oct 14 17:55:43 UTC 2013 i686 i686 i686 GNU/Linux
[root@localhost wilcal]# urpmi glibc
Package glibc-2.17-7.1.mga3.i586 is already installed

seems like it has come back just fine.

Intel, P4 530J 3.0 GHz, 800MHz FSB, 1MB L2, LGA 775
GigaByte  GA-81915G Pro F4  i915G  LGA 775  MoBo
 Marvel Yukon 88E8001 Gigabit LAN
 Intel High Def Audio, Azalia (C-Media 9880) (snd-hda-intel)
 Intel Graphics Media Accelerator 900 (Intel 82915G)
Comment 33 William Kenney 2013-10-16 00:27:11 CEST
Looks like there's a problem with just Vbox M3 32-bit.
Comment 34 Bill Wilkinson 2013-10-17 18:17:29 CEST
Booted normally mga2-32, using both kernel 3.4.66-1 server and desktop, dkms for nvidia builds properly.

Card:NVIDIA GeForce 6100 to GeForce 7950: NVIDIA Corporation|NV44A [GeForce 6200] [DISPLAY_VGA] (vendor:10de device:0221 subv:196e subd:02f3) (rev: a1)

Sempron 3000+ processor.
Comment 35 William Kenney 2013-10-17 18:54:08 CEST
On real hardware w/nVidia, M3, KDE, 64-bit
nvidia-current-kernel-desktop-latest

[root@localhost wilcal]# uname -a
Linux localhost 3.8.13.4-desktop-1.mga3 #1 SMP Thu Jul 4 13:56:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi kernel-desktop-latest
Package kernel-desktop-latest-3.8.13.4-1.mga3.x86_64 is already installed
KDE system operating normally.


Install glibc & kernel-desktop-latest updates from core updates_testing:

reboot system

[root@localhost wilcal]# uname -a
Linux localhost 3.10.16-desktop-1.mga3 #1 SMP Mon Oct 14 17:29:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi kernel-desktop-latest
Package kernel-desktop-latest-3.10.16-1.mga3.x86_64 is already installed
During boot the following error is displayed:

The display driver has been automatically switched to 'nouveau'
Reason: The proprietary kernel driver was not found for x.org driver 'nvidia'

seems like it has come back just fine using nouveau.
Duing the updates_testing installs what nvidia files need to be installed?

I went back to the MCC -> Hardware and let it reset up the nVidia driver
and on reboot the system hung during the boot process. So either I don't
understand the process to update the nVidia driver during this update
or their is something wrong here.

Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
VirtualBox 4.2.16-1.mga3.x86_64.rpm
Comment 36 roelof Wobben 2013-10-21 15:21:56 CEST
I only tested glibc and get this output:

urpmi glibc
A requested package cannot be installed:
glibc-2.17-5.mga3.x86_64 (in order to keep glibc-2.17-7.1.mga3.x86_64)
Continue installation anyway? (Y/n) y
While some packages may have been installed, there were failures.
A requested package cannot be installed:
glibc-2.17-5.mga3.x86_64 (in order to keep glibc-2.17-7.1.mga3.x86_64)
Continue installation anyway?

Uname -a :"Linux localhost 3.10.16-desktop-1.mga3 #1 SMP Mon Oct 14 17:29:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Roelof
Comment 37 William Kenney 2013-10-21 15:54:20 CEST
I'm having a LOT of problems with my local repo this
morning after it updated this morning. Likely theirs
a problem with the repos after the weekend Mageia
server shutdown. I'm gonna wait 24-hours before
resuming testing.
Comment 38 claire robinson 2013-10-21 16:01:51 CEST
Seems you already have the updated glibc Roelof, see comment 22.
Comment 39 Dave Hodgins 2013-10-22 03:58:28 CEST
Testing the pocs on m2 and m3 i586, they no longer segfault. However,
instead of consuming all ram like on x86_64 before the update, they
use a small amount of ram, and 100% cpu of one core, until killed.

In my opinion, this fix is worse than the problem it's supposed to
fix.

I haven't yet tested the "fix" on x86_64 for either release, as
they didn't cause problems prior to the "fix".

I'll test those shortly.
Comment 40 Dave Hodgins 2013-10-22 04:16:28 CEST
On both m2 and m3 x86_64, running the pocs shows no change. The pocs run till ram
and swap are used up, and then get killed.
Comment 41 Dave Hodgins 2013-10-22 22:04:52 CEST
Created attachment 4443 [details]
Source code from poc

Here's the source code from the poc, that was casuing a segfault with the prior glibc/kernel. Now it goes into a hard cpu loop. Strace shows it's not doing much before it goes into the loop.
10881 execve("./malloctest", ["./malloctest"], [/* 95 vars */]) = 0
10881 brk(0)                            = 0x901c000
10881 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb775f000
10881 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
10881 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
10881 fstat64(3, {st_mode=S_IFREG|0644, st_size=110812, ...}) = 0
10881 mmap2(NULL, 110812, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7743000
10881 close(3)                          = 0
10881 open("/lib/i686/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
10881 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\233\1\0004\0\0\0"..., 512) = 512
10881 fstat64(3, {st_mode=S_IFREG|0755, st_size=2020748, ...}) = 0
10881 mmap2(NULL, 1784572, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb758f000
10881 mmap2(0xb773d000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ae) = 0xb773d000
10881 mmap2(0xb7740000, 11004, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7740000
10881 close(3)                          = 0
10881 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb758e000
10881 set_thread_area({entry_number:-1 -> 6, base_addr:0xb758e6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
10881 mprotect(0xb773d000, 8192, PROT_READ) = 0
10881 mprotect(0x8049000, 4096, PROT_READ) = 0
10881 mprotect(0xb777f000, 4096, PROT_READ) = 0
10881 munmap(0xb7743000, 110812)        = 0
10881 mmap2(NULL, 429498368, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x9dbf4000
10881 brk(0)                            = 0x901c000
10881 brk(0x903d000)                    = 0x903d000
10881 open("/usr/share/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
10881 fstat64(3, {st_mode=S_IFREG|0644, st_size=3239280, ...}) = 0
10881 mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x9d9f4000
10881 mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x303) = 0xb775e000
10881 close(3)                          = 0
10881 --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
10881 +++ killed by SIGINT +++
Comment 42 David Walser 2013-10-23 02:48:50 CEST
CVE request for another security issue in glibc:
http://openwall.com/lists/oss-security/2013/10/22/12
Comment 43 David Walser 2013-10-23 04:41:10 CEST
CVE-2013-4458 has been allocated:
http://openwall.com/lists/oss-security/2013/10/23/4
Comment 44 claire robinson 2013-10-23 09:21:10 CEST
Will you want a new build for this Thomas?
Comment 45 Thomas Backlund 2013-10-25 21:06:03 CEST
I will try to set up a i586 system this WE to see if I can reproduce the issues Dave found...

Additional fix:

- Fix stack overflow due to large AF_INET6 requests (CVE-2013-4458)

new rpms (currently building):
advisory updated:


Mageia 2:
SRPM:
glibc-2.14.1-11.2.mga2.src.rpm

i586:
glibc-2.14.1-11.2.mga2.i586.rpm
glibc-devel-2.14.1-11.2.mga2.i586.rpm
glibc-doc-2.14.1-11.2.mga2.noarch.rpm
glibc-doc-pdf-2.14.1-11.2.mga2.noarch.rpm
glibc-i18ndata-2.14.1-11.2.mga2.i586.rpm
glibc-profile-2.14.1-11.2.mga2.i586.rpm
glibc-static-devel-2.14.1-11.2.mga2.i586.rpm
glibc-utils-2.14.1-11.2.mga2.i586.rpm
nscd-2.14.1-11.2.mga2.i586.rpm

x86_64:
glibc-2.14.1-11.2.mga2.x86_64.rpm
glibc-devel-2.14.1-11.2.mga2.x86_64.rpm
glibc-doc-2.14.1-11.2.mga2.noarch.rpm
glibc-doc-pdf-2.14.1-11.2.mga2.noarch.rpm
glibc-i18ndata-2.14.1-11.2.mga2.x86_64.rpm
glibc-profile-2.14.1-11.2.mga2.x86_64.rpm
glibc-static-devel-2.14.1-11.2.mga2.x86_64.rpm
glibc-utils-2.14.1-11.2.mga2.x86_64.rpm
nscd-2.14.1-11.2.mga2.x86_64.rpm


Mageia 3:
SRPM:
glibc-2.17-7.2.mga3.src.rpm

i586:
glibc-2.17-7.2.mga3.i586.rpm
glibc-devel-2.17-7.2.mga3.i586.rpm
glibc-doc-2.17-7.2.mga3.noarch.rpm
glibc-i18ndata-2.17-7.2.mga3.i586.rpm
glibc-profile-2.17-7.2.mga3.i586.rpm
glibc-static-devel-2.17-7.2.mga3.i586.rpm
glibc-utils-2.17-7.2.mga3.i586.rpm
nscd-2.17-7.2.mga3.i586.rpm

x86_64:
glibc-2.17-7.2.mga3.x86_64.rpm
glibc-devel-2.17-7.2.mga3.x86_64.rpm
glibc-doc-2.17-7.2.mga3.noarch.rpm
glibc-i18ndata-2.17-7.2.mga3.x86_64.rpm
glibc-profile-2.17-7.2.mga3.x86_64.rpm
glibc-static-devel-2.17-7.2.mga3.x86_64.rpm
glibc-utils-2.17-7.2.mga3.x86_64.rpm
nscd-2.17-7.2.mga3.x86_64.rpm
Comment 46 claire robinson 2013-10-28 22:19:55 CET
Testing mga3 32

Before
------
$ gcc malloc.c -o malloc
$ rpm -q glibc
glibc-2.17-5.mga3
$ ./malloc
Segmentation fault

After
-----
$ rpm -q glibc
glibc-2.17-7.2.mga3

It makes changes to /etc/nsswitch.conf 

-passwd:		files
-shadow:		files
-group:		files
+passwd:		compat
+shadow:		files nis
+group:		compat

-hosts:  	 mdns4_minimal files nis dns myhostname mdns4  wins
+hosts:  	files nis dns wins

-automount:	files
+automount:	files nis

Is this intended?


Confirmed Dave's findings. It sits with 100% cpu and about 20% ram.

Run under strace shows not very much..

$ strace ./malloc
execve("./malloc", ["./malloc"], [/* 57 vars */]) = 0
brk(0)                                  = 0x9764000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77d8000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=106922, ...}) = 0
mmap2(NULL, 106922, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77bd000
close(3)                                = 0
open("/lib/i686/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\233\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=2020748, ...}) = 0
mmap2(NULL, 1784572, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7609000
mmap2(0xb77b7000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ae) = 0xb77b7000
mmap2(0xb77ba000, 11004, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb77ba000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7608000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb76086c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb77b7000, 8192, PROT_READ)   = 0
mprotect(0x8049000, 4096, PROT_READ)    = 0
mprotect(0xb77f8000, 4096, PROT_READ)   = 0
munmap(0xb77bd000, 106922)              = 0
mmap2(NULL, 429498368, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x9dc6e000
brk(0)                                  = 0x9764000
brk(0x9785000)                          = 0x9785000
open("/usr/share/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=10972576, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x9da6e000
mmap2(NULL, 1503232, PROT_READ, MAP_PRIVATE, 3, 0x1f3) = 0x9d8ff000
mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0xa69) = 0xb77d7000
close(3)                                = 0


It sits like this until it's terminated.


^C--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
Process 3307 detached
Comment 47 claire robinson 2013-10-29 14:47:36 CET
Testing mga2 32

Same issue.

$ rpm -q glibc
glibc-2.14.1-11.2.mga2

$ strace ./malloc
execve("./malloc", ["./malloc"], [/* 91 vars */]) = 0
brk(0)                                  = 0x89c8000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb76eb000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=152354, ...}) = 0
mmap2(NULL, 152354, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb76c5000
close(3)                                = 0
open("/lib/i686/libc.so.6", O_RDONLY)   = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\225\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1794136, ...}) = 0
mmap2(NULL, 1563224, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7547000
mmap2(0xb76bf000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x178) = 0xb76bf000
mmap2(0xb76c2000, 10840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76c2000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7546000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb75466c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb76bf000, 8192, PROT_READ)   = 0
mprotect(0xb7709000, 4096, PROT_READ)   = 0
munmap(0xb76c5000, 152354)              = 0
mmap2(NULL, 429498368, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x9dbac000
brk(0)                                  = 0x89c8000
brk(0x89e9000)                          = 0x89e9000
open("/usr/share/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=17123692, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x9d9ac000
mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x40e) = 0x9d9ab000
mmap2(NULL, 1503232, PROT_READ, MAP_PRIVATE, 3, 0x767) = 0x9d83c000
close(3)                                = 0
^C
Comment 48 claire robinson 2013-10-29 14:50:18 CET
Adding feedback marker for now
Comment 49 claire robinson 2013-11-07 22:33:28 CET
Assigning Thomas for now. 

Please reassign to QA when when you've had a chance to take a look. 

Thanks.
Comment 50 Thomas Backlund 2013-11-20 22:52:53 CET
(In reply to Dave Hodgins from comment #39)
> Testing the pocs on m2 and m3 i586, they no longer segfault. However,
> instead of consuming all ram like on x86_64 before the update, they
> use a small amount of ram, and 100% cpu of one core, until killed.
> 
> In my opinion, this fix is worse than the problem it's supposed to
> fix.


Ok, I finally got around to test it on mga2, mga3, cauldron and upstream code, 
and they all behave the same.

And according to upstream it's expected behaviour:

<quote>
> What is a reasonable runtime to expect on those PoCs post-patch?

It should finish a few minutes before forever :)

The *_nocache code is O(n^3) (IIRC), so it's very very slow.  If it has to crash due to a buffer or stack overflow, it ought to be gone in a few minutes based on some arbitrary tests I did by introducing buffer overflows and accesses beyond bounds in the code.
</quote>

wich explains why it keeps the cpu busy without dropping out.

and as that exploit was 32bit specific, it explains why there
is no change in behaviour on 64bit

So this is ready to be pushed as it has some important fixes...

I decided to rewrite a better advisory like this (also committed to svn):



Updated glibc packages fixes the following security issues:

Integer overflow in string/strcoll_l.c in the GNU C Library (aka glibc
or libc6) 2.17 and earlier allows context-dependent attackers to cause
a denial of service (crash) or possibly execute arbitrary code via a
long string, which triggers a heap-based buffer overflow. (CVE-2012-4412)

Stack-based buffer overflow in string/strcoll_l.c in the GNU C Library
(aka glibc or libc6) 2.17 and earlier allows context-dependent
attackers to cause a denial of service (crash) or possibly execute
arbitrary code via a long string that triggers a malloc failure and
use of the alloca function. (CVE-2012-4424)

pt_chown in GNU C Library (aka glibc or libc6) before 2.18 does not
properly check permissions for tty files, which allows local users to
change the permission on the files and obtain access to arbitrary
pseudo-terminals by leveraging a FUSE file system. (CVE-2013-2207)
NOTE! This is fixed by removing pt_chown wich may break chroots
      if their devpts was not mounted correctly. 
      (make sure to mount the devpts correctly with gid=5)

sysdeps/posix/readdir_r.c in the GNU C Library (aka glibc or libc6)
2.18 and earlier allows context-dependent attackers to cause a denial
of service (out-of-bounds write and crash) or possibly execute
arbitrary code via a crafted (1) NTFS or (2) CIFS image. (CVE-2013-4237)

Multiple integer overflows in malloc/malloc.c in the GNU C Library
(aka glibc or libc6) 2.18 and earlier allow context-dependent
attackers to cause a denial of service (heap corruption) via a large
value to the (1) pvalloc, (2) valloc, (3) posix_memalign, (4)
memalign, or (5) aligned_alloc functions. (CVE-2013-4332)

A stack (frame) overflow flaw, which led to a denial of service 
(application crash), was found in the way glibc's getaddrinfo() function
processed certain requests when called with AF_INET6. A similar flaw to
CVE-2013-1914, this affects AF_INET6 rather than AF_UNSPEC (CVE-2013-4458).

The PTR_MANGLE implementation in the GNU C Library (aka glibc or libc6)
2.4, 2.17, and earlier, and Embedded GLIBC (EGLIBC) does not initialize
the random value for the pointer guard, which makes it easier for context-
dependent attackers to control execution flow by leveraging a buffer-
overflow vulnerability in an application and using the known zero value
pointer guard to calculate a pointer address. (CVE-2013-4788)

Other fixes in this update:
- Correct the processing of '\x80' characters in crypt_freesec.c
- drop minimal required kernel to 2.6.32 so it works in chroots on top
  of enterprise kernels and for OpenVZ users.
- fix typo in nscd.service
Comment 51 Samuel Verschelde 2013-11-21 10:28:03 CET
Ive been using this glibc for several days, if not weeks. Not problem. Mga2 x86_64
Comment 52 claire robinson 2013-11-21 10:45:37 CET
Validating, thankyou. Adding whiteboard markers from previous/current testing. Added some indentation in the advisory.

Could you please push from 2&3 core/updates_testing to updates.

Thanks!
Comment 53 David Walser 2013-11-21 15:35:36 CET
Do we know anything about CVE-2013-0242 and CVE-2013-1914 from this RHEL6 advisory?

https://rhn.redhat.com/errata/RHSA-2013-1605.html
Comment 54 Thomas Backlund 2013-11-21 15:42:43 CET
(In reply to David Walser from comment #53)
> Do we know anything about CVE-2013-0242 and CVE-2013-1914 from this RHEL6
> advisory?
> 
> https://rhn.redhat.com/errata/RHSA-2013-1605.html

Yep, alrady fixed in mga2:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2013-0141

and in mga3 release
Comment 55 Thomas Backlund 2013-11-22 20:22:03 CET
Update pushed:
http://advisories.mageia.org/MGASA-2013-0340.html

Note You need to log in before you can comment on or make changes to this bug.