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:
Whiteboard: (none) => MGA3TOO, MGA2TOO
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..
Status: NEW => ASSIGNED
There's also CVE-2013-4332 in Bug 11223.
Summary: glibc new security issues CVE-2012-4412 CVE-2012-4424 CVE-2013-2207 CVE-2013-4237 => glibc new security issues CVE-2012-4412 CVE-2012-4424 CVE-2013-2207 CVE-2013-4237 CVE-2013-4332
Blocks: (none) => 11223
Cauldron glibc-2.18 pushed to /release
Version: Cauldron => 3Whiteboard: MGA3TOO, MGA2TOO => MGA2TOO
Hardware: i586 => All
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/
Summary: glibc new security issues CVE-2012-4412 CVE-2012-4424 CVE-2013-2207 CVE-2013-4237 CVE-2013-4332 => glibc new security issues CVE-2012-4412 CVE-2012-4424 CVE-2013-2207 CVE-2013-4237 CVE-2013-4332 CVE-2013-4788
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
CC: (none) => tmbAssignee: tmb => qa-bugs
*** Bug 11223 has been marked as a duplicate of this bug. ***
CC: (none) => oe
Why don't you use subrel here?
Because its not required... The upgrade path is ensured with version changes: mga2: 2.14.1 -> mga3: 2.17 -> mga4: 2.18
Well, updates policy says "If the version didn't change, leave mkrel as is and '%define subrel 1'" :)
CC: (none) => stormi
Direct links to the RHBZ with further info and PoCs: CVE-2012-4412: https://bugzilla.redhat.com/show_bug.cgi?id=855385 CVE-2012-4424: https://bugzilla.redhat.com/show_bug.cgi?id=858238 CVE-2013-2207: https://bugzilla.redhat.com/show_bug.cgi?id=976408 CVE-2013-4237: https://bugzilla.redhat.com/show_bug.cgi?id=995839 CVE-2013-4332: https://bugzilla.redhat.com/show_bug.cgi?id=1007545 CVE-2013-4788: https://bugzilla.redhat.com/show_bug.cgi?id=985625
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
CC: (none) => wilcal.intWhiteboard: MGA2TOO => MGA2TOO MGA3-32-OK
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
Whiteboard: MGA2TOO MGA3-32-OK => MGA2TOO MGA3-32-OK MGA3-64-OK
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
Whiteboard: MGA2TOO MGA3-32-OK MGA3-64-OK => MGA2TOO MGA3-32-OK MGA3-64-OK MGA2-32-OK
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
Whiteboard: MGA2TOO MGA3-32-OK MGA3-64-OK MGA2-32-OK => MGA2TOO MGA3-32-OK MGA3-64-OK MGA2-32-OK MGA2-64-OK
(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.
(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.
CC: (none) => davidwhodgins
Whiteboard: MGA2TOO MGA3-32-OK MGA3-64-OK MGA2-32-OK MGA2-64-OK => MGA2TOO
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.
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?
CC: (none) => lewyssmith
====================================================== 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.
Advisory 11059.adv committed to svn
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
Assignee: qa-bugs => tmb
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...
Assignee: tmb => qa-bugs
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.
Depends on: (none) => 11463
Depends on: (none) => 11468
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.
CC: (none) => wrw105
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.
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.
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.
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
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
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
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.
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)
Looks like there's a problem with just Vbox M3 32-bit.
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.
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
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
CC: (none) => rwobben
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.
Seems you already have the updated glibc Roelof, see comment 22.
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.
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.
Whiteboard: MGA2TOO => MGA2TOO feedback
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 +++
CVE request for another security issue in glibc: http://openwall.com/lists/oss-security/2013/10/22/12
CVE-2013-4458 has been allocated: http://openwall.com/lists/oss-security/2013/10/23/4
Will you want a new build for this Thomas?
CC: lewyssmith => (none)
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
Summary: glibc new security issues CVE-2012-4412 CVE-2012-4424 CVE-2013-2207 CVE-2013-4237 CVE-2013-4332 CVE-2013-4788 => glibc new security issues CVE-2012-4412 CVE-2012-4424 CVE-2013-2207 CVE-2013-4237 CVE-2013-4332 CVE-2013-4458 CVE-2013-4788Whiteboard: MGA2TOO feedback => MGA2TOO
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
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
Adding feedback marker for now
Assigning Thomas for now. Please reassign to QA when when you've had a chance to take a look. Thanks.
CC: (none) => qa-bugsAssignee: qa-bugs => tmb
Whiteboard: MGA2TOO feedback => MGA2TOO
(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
Ive been using this glibc for several days, if not weeks. Not problem. Mga2 x86_64
Whiteboard: MGA2TOO => MGA2TOO MGA2-64-OK
Whiteboard: MGA2TOO MGA2-64-OK => MGA2TOO advisory MGA2-64-OK
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!
Keywords: (none) => validated_updateWhiteboard: MGA2TOO advisory MGA2-64-OK => MGA2TOO advisory mga2-32-ok MGA2-64-OK mga3-32-ok mga3-64-okCC: (none) => sysadmin-bugs
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
(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
Update pushed: http://advisories.mageia.org/MGASA-2013-0340.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED