Integer signedness error in Glibc before 2.13 and eglibc before 2.13, when using Supplemental Streaming SIMD Extensions 3 (SSSE3) optimization, allows context-dependent attackers to execute arbitrary code via a negative length parameter to (1) memcpy-ssse3-rep.S, (2) memcpy-ssse3.S, or (3) memset-sse2.S in sysdeps/i386/i686/multiarch/, which triggers an out-of-bounds read, as demonstrated using the memcpy function.

Stack-based buffer overflow in the getaddrinfo function in sysdeps/posix/getaddrinfo.c in GNU C Library (aka glibc or libc6) 2.18 and earlier allows remote attackers to cause a denial of service (crash) via a (1) hostname or (2) IP address that triggers a large number of AFINET6 address results. NOTE: this vulnerability exists because of an incomplete fix for CVE-2013-1914.

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) posixmemalign, (4) memalign, or (5) alignedalloc functions.

The PTRMANGLE 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.

Harald van Dijk discovered [1],[2] that glibc's locale command does not sufficiently sanitize the user environment. According to POSIX specifications [3], the output of the 'locale' command must be appropriately quoted and safe to execute, in order to restore the locale after temporarily forcing a change (such as LCALL=C). However, this is not the case with glibc versions up to and including 2.12.1:

LANG=' rm -rf /' locale locale: Cannot set LCCTYPE to default locale: No such file or directory locale: Cannot set LCMESSAGES to default locale: No such file or directory locale: Cannot set LCALL to default locale: No such file or directory LANG= rm -rf / LCCTYPE=" rm -rf /" LCNUMERIC=" rm -rf /" LCTIME=" rm -rf /" LCCOLLATE=" rm -rf /" LCMONETARY=" rm -rf /" LCMESSAGES=" rm -rf /" LCPAPER=" rm -rf /" LCNAME=" rm -rf /" LCADDRESS=" rm -rf /" LCTELEPHONE=" rm -rf /" LCMEASUREMENT=" rm -rf /" LCIDENTIFICATION=" rm -rf /" LCALL=

Any script that does "eval $(locale)" or something similar will execute the unquoted commands.

The POSIX specification states:

"The <value> and <implied value> shown above shall be properly quoted for possible later reentry to the shell. The <value> shall not be quoted using double-quotes (so that it can be distinguished by the user from the <implied value> case, which always requires double-quotes)."

This has been corrected upstream [4].

[1] http://bugs.gentoo.org/showbug.cgi?id=330923 [2] http://sources.redhat.com/bugzilla/showbug.cgi?id=11904 [3] http://www.opengroup.org/onlinepubs/000095399/utilities/locale.html [4] http://sourceware.org/git/?p=glibc.git;a=patch;h=026373745eab50a683536d950cb7e17dc98c4259

Integer overflow in posix/fnmatch.c in the GNU C Library (aka glibc or libc6) 2.13 and earlier allows context-dependent attackers to cause a denial of service (application crash) via a long UTF8 string that is used in an fnmatch call with a crafted pattern argument, a different vulnerability than CVE-2011-1071.