On Tue, Jul 2, 2013 at 12:52 PM, Alexandre Oliva aol...@redhat.com wrote:
At this point, I'd rather we took the opportunity to fix code that makes
unsafe assumptions about the behavior of crypt than push the problem on
for users to figure out when a glibc upgrade causes passwords to fail to
be
Control: found -1 2.11.3-1
Hi,
The upstream commit referenced above isn't enough for, at least,
squeeze's 2.11.3.
There's another stack overflow in gaih_inet when calling gethostbyname4_r.
2.17 uses malloc if needed, and git blames the following commit for
those changes:
Processing control commands:
found -1 2.11.3-1
Bug #704623 {Done: Aurelien Jarno aure...@debian.org} [eglibc] eglibc:
CVE-2013-1914: getaddrinfo() stack overflow
There is no source info for the package 'eglibc' at version '2.11.3-1' with
architecture ''
Unable to make a source version for
Please see my bug report for CVS documenting this behavior as well
as my patch: https://savannah.nongnu.org/bugs/?39040
--mancha
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Dear all:
You might be interested in a project of mine which humbly began
as helping the Slackware Linux team patch their Shadow tools
suite to properly handle possible NULL returns from glibc 2.17+
crypt().
It since has evolved into a larger project where I have been
working with developers to
5 matches
Mail list logo
