From ${URL} : David Reid, Glyph Lefkowitz, and myself discovered a bug in glibc ( https://sourceware.org/bugzilla/show_bug.cgi?id=17048) which can, in conjunction with many common memory management techniques from an application (read: we hit this issue repeatedly developing our Python application), lead to a use after free, or other vulnerabilities. Is it within policy to issue a CVE for glibc in a case like this? Thanks to the Red Hat security team for assisting in triaging this and working with the Glibc maintainers. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Fixed in 2.20
backported to glibc-2.19-r1 http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.19/00_all_0012-posix_spawn_file_actions_addopen-needs-to-copy-the-p.patch?rev=1.1 http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.19/00_all_0013-posix_spawn_faction_addopen-Add-missing-string.h-inc.patch?rev=1.1
Is there a way to backport to 2.17/2.18 ? Which version we need to stabilize?
i'm not planning on backporting past 2.19, nor stabilizing 2.18. we'll most likely stabilize 2.19 next.
CVE-2014-4043 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-4043): The posix_spawn_file_actions_addopen function in glibc before 2.20 does not copy its path argument in accordance with the POSIX specification, which allows context-dependent attackers to trigger use-after-free vulnerabilities.
Maintainer(s), please drop the vulnerable version(s). Added to an existing GLSA Request.
This issue was resolved and addressed in GLSA 201503-04 at http://security.gentoo.org/glsa/glsa-201503-04.xml by GLSA coordinator Kristian Fiskerstrand (K_F).
