This looks dangerous: https://googleonlinesecurity.blogspot.de/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
The Debian Security Advisory for CVE-2015-7547 [1] lists 3 more CVEs for glibc: CVE-2015-8776 CVE-2015-8778 CVE-2015-8779 [1] https://lists.debian.org/debian-security-announce/2016/msg00051.html
Just to get everyone on the same page: Sorry for not filing a bug earlier. We have been aware of this vulnerability through the pre-notification channels. We had already discussed with vapier that we will provide an updated package once the issue is released, instead of preparing a package based on the non-final patches.
"we will provide an updated package once the issue is released, instead of preparing a package based on the non-final patches." What do you mean by that? The issue is released, there is an official patch from the glibc developers. Do you mean you want to wait until there is an updated glibc release? I don't know if that's going to happen any time soon, the announcement doesn't say anything about that (based on past experiences glibc releases don't automatically happen after security issues). And I think this issue is definitely severe enough that an update should happen within hours, not days.
i'm taking care of it. don't bother kicking over semantics.
(In reply to Matthias Maier from comment #1) > The Debian Security Advisory for CVE-2015-7547 [1] lists 3 more CVEs for > glibc: > > CVE-2015-8776 > CVE-2015-8778 > CVE-2015-8779 > > [1] https://lists.debian.org/debian-security-announce/2016/msg00051.html they are reported in bug 572416
(In reply to Hanno Boeck from comment #3) > "we will provide an updated package once the issue is released, instead of > preparing a package based on the non-final patches." > > What do you mean by that? The issue is released, there is an official patch > from the glibc developers. > > Do you mean you want to wait until there is an updated glibc release? I > don't know if that's going to happen any time soon, the announcement doesn't > say anything about that (based on past experiences glibc releases don't > automatically happen after security issues). And I think this issue is > definitely severe enough that an update should happen within hours, not > days. I mean that, for severe issues like this one, we usually prepare updated packages during the embargo period so that we are ready to commit it *the minute* it is released. In this case we didn't do that, and seeing that multiple people have already pinged us about whether we're aware of this bug, I merely wanted to assure everyone that we're aware and that a fixed package will be available soon. :) Sorry about the confusion.
In the meantime, I backported the patch from https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html to apply cleanly to at least sys-libs/glibc-2.21-r1 Throw http://codepad.org/NiV9JoCF in /etc/portage/patches/sys-libs/glibc/CVE-2015-7547.patch and re-emerge glibc. Disclaimer: I am not a security expert, and have not reviewed the patch's logic at all. Use at your own risk, and definitely upgrade to the official Gentoo fix as soon as it is released (don't forget to remove the /etc/portage/patches/... file!).
the fix is included in glibc-2.21-r2 so it should be easier/safer to stabilize (rather than jump 2.21 to 2.22)
Created attachment 425664 [details, diff] patch for sys-libs/glibc-2.22-r1 Here is the patch from upstream, rebased to apply to sys-libs/glibc-2.22-r1 in the Portage tree. (I just had to add four additional lines for the patch to delete. Luke-Jr's patch from Comment 7 did not apply cleanly to 2.22-r1.) Drop this patch into /etc/portage/patches/sys-libs/glibc-2.22-r1/CVE-2015-7547.patch and re-emerge sys-libs/glibc.
(In reply to SpanKY from comment #8) > the fix is included in glibc-2.21-r2 so it should be easier/safer to > stabilize (rather than jump 2.21 to 2.22) Thanks! Arches, please test and mark stable: =sys-libs/glibc-2.22-r1 Target keywords : "alpha amd64 arm arm64 hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
(In reply to Tobias Heinlein from comment #10) > (In reply to SpanKY from comment #8) > > the fix is included in glibc-2.21-r2 so it should be easier/safer to > > stabilize (rather than jump 2.21 to 2.22) > > Thanks! > > Arches, please test and mark stable: > =sys-libs/glibc-2.22-r1 > Target keywords : "alpha amd64 arm arm64 hppa ia64 m68k ppc ppc64 s390 sh > sparc x86" Sorry, I meant 2.21-r2 of course.
(In reply to Tobias Heinlein from comment #11) > Sorry, I meant 2.21-r2 of course. Any ETA for a 2.22-r2?
(In reply to Tobias Klausmann from comment #12) 2.22-r2 will need to bake for 30 days. there's some locale changes in there.
amd64 stable (helpful tip - if you do your commits using repoman commit you'll spot invalid copyrights)
x86 stable Another helpful tip for users: If the build fails for you, try MAKEOPTS="-j1". See bug #574948 for details.
Stable for alpha/arm/ia64/ppc/ppc64/sparc
This issue was resolved and addressed in GLSA 201602-02 at https://security.gentoo.org/glsa/201602-02 by GLSA coordinator Tobias Heinlein (keytoaster).
Reopening for remaining arches.
i've done the remaining arches
