Calling NSS-backed functions that support caching via nscd may call the nscd client side code and in the GNU C Library version 2.36 under high load on x8664 systems, the client may call memcmp on inputs that are concurrently modified by other processes or threads and crash.

The nscd client in the GNU C Library uses the memcmp function with inputs that may be concurrently modified by another thread, potentially resulting in spurious cache misses, which in itself is not a security issue.  However in the GNU C Library version 2.36 an optimized implementation of memcmp was introduced for x8664 which could crash when invoked with such undefined behaviour, turning this into a potential crash of the nscd client and the application that uses it. This implementation was backported to the 2.35 branch, making the nscd client in that branch vulnerable as well.  Subsequently, the fix for this issue was backported to all vulnerable branches in the GNU C Library repository.

It is advised that distributions that may have cherry-picked the memcpy SSE2 optimization in their copy of the GNU C Library, also apply the fix to avoid the potential crash in the nscd client.

Calling getnetbyaddr or getnetbyaddrr with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.

The regcomp function in the GNU C library version from 2.4 to 2.41 is subject to a double free if some previous allocation fails. It can be accomplished either by a malloc failure or by using an interposed malloc that injects random malloc failures. The double free can allow buffer manipulation depending of how the regex is constructed. This issue affects all architectures and ABIs supported by the GNU C library.

The strncmp implementation optimized for the Power10 processor in the GNU C Library version 2.40 and later writes to vector registers v20 to v31 without saving contents from the caller (those registers are defined as non-volatile registers by the powerpc64le ABI), resulting in overwriting of its contents and potentially altering control flow of the caller, or leaking the input strings to the function to other parts of the program.

When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.

endpattern (called from internalfnmatch) in the GNU C Library (aka glibc or libc6) before 2.22 might allow context-dependent attackers to cause a denial of service (application crash), as demonstrated by use of the fnmatch library function with the (!() pattern. NOTE: this is not the same as CVE-2015-8984; also, some Linux distributions have fixed CVE-2015-8984 but have not fixed this additional fnmatch issue.

The deprecated compatibility function clntcreate in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its hostname argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.

Reference: https://sourceware.org/bugzilla/showbug.cgi?id=22542

The deprecated compatibility function svcunixcreate in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its path argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.

Reference: https://sourceware.org/bugzilla/showbug.cgi?id=28768

A flaw was found in glibc. An integer overflow in the implementation of the posixmemalign in memalign functions in the GNU C Library (aka glibc or libc6) 2.26 and earlier could cause these functions to return a pointer to a heap area that is too small, potentially leading to heap corruption.

References: https://sourceware.org/bugzilla/showbug.cgi?id=22343

Patch: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8e448310d74b283c5cd02b9ed7fb997b47bf9b22

The ADDW macro in stdio-common/vfscanf.c in the GNU C Library (aka glibc or libc6) before 2.21 does not properly consider data-type size during a risk-management decision for use of the alloca function, which might allow context-dependent attackers to cause a denial of service (segmentation violation) or overwrite memory locations beyond the stack boundary via a long line containing wide characters that are improperly handled in a wscanf call.

It was reported [1] that scanf and related functions are crashing due to a bug [2] in glibc.

[1]: http://seclists.org/oss-sec/2015/q1/686 [2]: https://sourceware.org/bugzilla/showbug.cgi?id=13138

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.

An out-of buffer bounds write flaw was found in the way the readdirr function in glibc, the GNU C Library, handled a directory entry whose file name name contained more byte than the NAMEMAX characters constant indicated. An attacker could provide a specially-crafted (local) NTFS or (remote) CIFS file system that, when processed in an application using the readdirr() function, would cause that application to crash or, potentially, execute arbitrary code with the privileges of the user running the application.

Upstream bug report: [1] http://sourceware.org/bugzilla/showbug.cgi?id=14699

Latest patch proposal: [2] http://sourceware.org/ml/libc-alpha/2013-05/msg00445.html

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.

There exists a integer overflow to buffer overflow vulnerability within tzfileread function of the GNU C Library. This vulnerability was published by dividead early in 2009 in the following blog post:

http://dividead.wordpress.com/2009/06/01/glibc-timezone-integer-overflow/

In December 3, Kingcope, at Full Disclosure Mailing List, noted vsftpd as one possible attack vector for this issue:

http://lists.grok.org.uk/pipermail/full-disclosure/2011-December/084452.html

DISPUTED ldd in the GNU C Library (aka glibc or libc6) 2.13 and earlier allows local users to gain privileges via a Trojan horse executable file linked with a modified loader that omits certain LDTRACELOADEDOBJECTS checks. NOTE: the GNU C Library vendor states "This is just nonsense. There are a gazillion other ways to introduce code if people are downloading arbitrary binaries and install them in appropriate directories or set LDLIBRARYPATH etc."

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

Following patch was applied to glibc packages to address dynamic linker privilege escalation issue CVE-2010-3847 (see bug #643306):

https://bugzilla.redhat.com/showbug.cgi?id=CVE-2010-3847#c26 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=4b646a51f13fd6816c483fb24c308a13264c6d1a

This change introduced a regression in handling of privileged programs that use $ORIGIN in RPATH in the binary itself, or any of the depending libraries. When running such privileged program, this issue causes dynamic linker to not expand $ORIGIN in RPATH and search for additional dynamic objects starting from the current working directory. This could allow a local user to escalate their privileges, or cause the program to fail to find required libraries.

Prior to the CVE-2010-3847, it was possible to escalate privileges when privileged program had $ORIGIN in RPATH. An attacker needed to have a write access to the file system hosting such binary, to be able to hard-link it to an attacker-controlled directory. Then the attacker could LDPRELOAD malicious library from the same directory and execute code with elevated privileges. This flaw was of limited risk, as setuid/setgid binaries with $ORIGIN in RPATH seem to be rare (there's no such binary in Red Hat Enterprise Linux).

With the 4b646a51 fix applied, attacker no longer needs write access to the file system with privileged program, and the relative-to-CWD search can be triggered by RPATHs of depending libraries too. Even with these loosened requirements, there are currently no privileged programs shipped with Red Hat Enterprise Linux known to be exploitable using this flaw.

To address this issue, 4b646a51 was reverted and the following patch was applied in fedora glibc git branch: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=96611391ad8823ba58405325d78cefeae5cdf699

Following patch is also required to avoid regressing CVE-2010-3847 fix: https://bugzilla.redhat.com/showbug.cgi?id=CVE-2010-3847#c22 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=22cd1c9bcf57c5829d65b6da825f7a459d40c9eb

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.

Certain run-time memory protection mechanisms in the GNU C Library (aka glibc or libc6) print argv[0] and backtrace information, which might allow context-dependent attackers to obtain sensitive information from process memory by executing an incorrect program, as demonstrated by a setuid program that contains a stack-based buffer overflow error, related to the fortifyfail function in debug/fortifyfail.c, and the stackchkfail (aka stack protection) and chkfail (aka FORTIFYSOURCE) implementations.

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.