From ${URL} : we are preparing the glibc 2.23 release upstream and have fixed the following security bugs which, to my best knowledge, lack public CVE assignment so far: Passing out of range data to strftime() causes a segfault https://sourceware.org/bugzilla/show_bug.cgi?id=18985 Out-of-range time values passed to the strftime function may cause it to crash, leading to a denial of service, or potentially disclosure information. LD_POINTER_GUARD is not ignored for privileged binaries https://sourceware.org/bugzilla/show_bug.cgi?id=18928 LD_POINTER_GUARD was an environment variable which controls security-related behavior, but was not ignored for privileged binaries (in AT_SECURE mode). This might allow local attackers (who can supply the environment variable) to bypass intended security restrictions. hcreate((size_t)-1) should fail with ENOMEM https://sourceware.org/bugzilla/show_bug.cgi?id=18240 This is an integer overflow in hcreate and hcreate_r which can result in an out-of-bound memory access. This could lead to application crashes or, potentially, arbitrary code execution. nan function unbounded stack allocation https://sourceware.org/bugzilla/show_bug.cgi?id=16962 A stack overflow (unbounded alloca) can cause applications which process long strings with the nan function to crash or, potentially, execute arbitrary code. catopen() Multiple unbounded stack allocations https://sourceware.org/bugzilla/show_bug.cgi?id=17905 A stack overflow (unbounded alloca) in the catopen function can cause applications which pass long strings to the catopen function to crash or, potentially execute arbitrary code. @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.
at least LD_POINTER_GUARD is already fixed in our 2.22-r1 ebuild, but some of those are most likely not
CVE-2015-8776 (strftime) is fixed for glibc-2.23 and cherry picked to 2.22 CVE-2015-8778 (hcreate) is still not fixed but is under discussion CVE-2014-9761 (nan) is fixed for glibc-2.23 and cherry picked to 2.22 CVE-2015-8779 (catopen) is fixed for glibc-2.23 and cherry picked to 2.22 once the hcreate issue is sorted out upstream, i'll roll a glibc-2.22-r2
i've got all the fixes queued for a 2.22-r2, but am waiting on CVE-2015-8778 to be resolved. they're blocking the 2.23 release on it, so it should be soon.
i've backported most of the fixes to 2.21-r2 and all of them to 2.22-r2 2.21-r2 will go stable via bug 574880, and 2.22-r2 will take time to bake
(In reply to SpanKY from comment #4) >> [...] >> CVE-2014-9761 (nan) is fixed for glibc-2.23 and cherry picked to 2.22 >> [...] > > i've backported most of the fixes to 2.21-r2 and all of them to 2.22-r2 > > 2.21-r2 will go stable via bug 574880, and 2.22-r2 will take time to bake Mike, according to your comment #4 the fix for CVE-2014-9761 (nan) should be included in -2.22-r4. Can you please help me identifying the patch? I failed to find it by name or grep. So from my view, we have _no_ fix for CVE-2014-9761 in stable.
maybe it didn't land in the glibc-2.22 patchset, so it's fixed in glibc-2.23+. i'm not going to backport it now. for future reference, don't file more than one issue in one bug. this was a pita to track, and now it'll be even more of a pain.
(In reply to SpanKY from comment #6) > maybe it didn't land in the glibc-2.22 patchset, so it's fixed in > glibc-2.23+. i'm not going to backport it now. > > for future reference, don't file more than one issue in one bug. this was a > pita to track, and now it'll be even more of a pain. Seriously? You explicitly stated you cherry picked the fix in a previous comment. You even elaborated on what fix you were waiting for. Now someone checks it and you complain? Yes, the bugs should can and will be dealt with in a cleaner manner.
(In reply to Aaron Bauman from comment #7) i have no idea wtf your problem is. i missed a patch out of many across multiple versions of glibc. i'm not complaining, i'm stating a fact. the fix i was tracking/waiting for earlier was not strtod/nan, it was hcreate, and that is in the 2.22 patchset. another set of facts are: - glibc-2.22-r4 is already in stable - glibc-2.23-r3 is already in unstable - adding any patches to 2.22 now won't see any testing before it goes stable - glibc-2.23 is most likely going to go stable in that time frame anyways - this particular issue does not appear to be serious you need to step back, chill out, and evaluate reality before yelling at people.
(In reply to SpanKY from comment #8) > (In reply to Aaron Bauman from comment #7) > > i have no idea wtf your problem is. i missed a patch out of many across > multiple versions of glibc. i'm not complaining, i'm stating a fact. > > the fix i was tracking/waiting for earlier was not strtod/nan, it was > hcreate, and that is in the 2.22 patchset. > > another set of facts are: > - glibc-2.22-r4 is already in stable > - glibc-2.23-r3 is already in unstable > - adding any patches to 2.22 now won't see any testing before it goes stable > - glibc-2.23 is most likely going to go stable in that time frame anyways > - this particular issue does not appear to be serious > > you need to step back, chill out, and evaluate reality before yelling at > people. I am not yelling at anyone. I don't do that. If you missed a patch that is fine, but don't tell us it was due to the bug report. You were clearly tracking it and said it was cherry picked. I agree, it can be painful with multiple vulnerabilities listed in one bug report. We will make sure it is done properly for future bugs. Although, what @ago does is up to him. I try and make sure we lay it out simply so the maintainers are not overwhelmed trying to find the appropriate patches. We will open a new bug considering latest stable does not have the patch. Once 2.23 goes stable we can address it then considering upstream included the patch. Again, not yelling at anyone and I would never do that. Missing a patch is not the end of the world. Thanks for your work and all that you do with base system.
This issue was resolved and addressed in GLSA 201702-11 at https://security.gentoo.org/glsa/201702-11 by GLSA coordinator Thomas Deutschmann (whissi).
