It was reported that if a process that called glibc's svcrun() exceeded the limit of opened files for a longer period of time, that accept() in rendezvousrequest()/svcudprecv() would fail with the EMFILE error, which would lead to looping between poll(), accept(), and 'for' loops which would consume a lot of CPU time. This could lead to an unresponsive system that requires human intervention (service restart or system restart) to resolve.

A security flaw was found in the way strcoll() interface of glibc, the GNU libc libraries, performed failsafe back to alloca() routine when malloc() function call failed previously (due to out of memory [OOM] condition for example). If an application linked against glibc was missing an application-level sanity checks for validity of strcoll() arguments and accepted untrusted input, an attacker could use this flaw to cause the particular application to crash or, potentially, execute arbitrary code with the privileges of the user running the application.

Upstream bug report (including the reproducer): [1] http://sourceware.org/bugzilla/showbug.cgi?id=14552#c0

Issue / part: 1) alloca() stack overflow from [1].

References: [2] http://www.openwall.com/lists/oss-security/2012/09/07/9 [3] http://www.openwall.com/lists/oss-security/2012/09/07/15 [4] http://www.openwall.com/lists/oss-security/2012/09/10/1 [5] http://www.openwall.com/lists/oss-security/2012/09/10/3 [6] http://www.openwall.com/lists/oss-security/2012/09/13/16

An integer overflow, leading to buffer overflow flaw was found in the way the implementation of strcoll() routine, used to compare two strings based on the current locale, of glibc, the GNU libc libraries, performed calculation of memory requirements / allocation, needed for storage of the strings. If an application linked against glibc was missing an application-level sanity checks for validity of strcoll() arguments and accepted untrusted input, an attacker could use this flaw to cause the particular application to crash or, potentially, execute arbitrary code with the privileges of the user running the application.

Upstream bug report (including reproducer): [1] http://sourceware.org/bugzilla/showbug.cgi?id=14547

It was discovered that the formatted printing functionality in glibc used extendalloca() incorrectly. A remote attacker could provide a specially crafted sequence of format specifiers, leading to a desynchronization within the buffer size handling, resulting in the use of uninitialized memory or, potentially, FORTIFYSOURCE format string protection mechanism bypass, when processed.

References: http://sourceware.org/bugzilla/showbug.cgi?id=13446 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a4647e727a2a52e1259474c13f4b13288938bed4