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.

Integer overflow in the tzfileread function in glibc before 2.15 allows context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted timezone (TZ) file, as demonstrated using vsftpd.

It was reported [1] that glibc had a bug where it would use alloca() for the length of a user-supplied UTF8 string, times four (with additional integer overflow in the times four). This could lead to an application crash, because alloca() extends the stack.

This was reported upstream [2] and subsequently fixed upstream [3].

References:

[1] http://scarybeastsecurity.blogspot.com/2011/02/i-got-accidental-code-execution-via.html [2] http://sourceware.org/bugzilla/showbug.cgi?id=11883 [3] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f15ce4d8dc139523fe0c273580b604b2453acba6

elf/dl-load.c in ld.so in the GNU C Library (aka glibc or libc6) through 2.11.2, and 2.12.x through 2.12.1, does not properly handle a value of $ORIGIN for the LDAUDIT environment variable, which allows local users to gain privileges via a crafted dynamic shared object (DSO) located in an arbitrary directory.

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.