CVE-2011-1071: Integer Overflow
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
Other sources
The GNU C Library (aka glibc or libc6) before 2.12.2 and Embedded GLIBC (EGLIBC) allow context-dependent attackers to execute arbitrary code or cause a denial of service (memory consumption) via a long UTF8 string that is used in an fnmatch call, aka a "stack extension attack," a related issue to CVE-2010-2898, CVE-2010-1917, and CVE-2007-4782, as originally reported for use of this library by Google Chrome.
— MITRE
Affected Software
Remediation
Patch Available
Patch Available
Event History
Frequently Asked Questions
What is the severity of CVE-2011-1071?
CVE-2011-1071 has a severity rating of medium due to its potential to cause application crashes.
How do I fix CVE-2011-1071?
To fix CVE-2011-1071, upgrade to a version of glibc that is not affected, specifically versions later than 2.12.1.
What are the affected versions for CVE-2011-1071?
CVE-2011-1071 affects multiple versions of GNU C Library (glibc) including 2.2, 2.3, and up to 2.12.1.
Can CVE-2011-1071 be exploited remotely?
CVE-2011-1071 is not typically exploited remotely as it generally requires user-supplied input.
What is the impact of CVE-2011-1071 on applications?
CVE-2011-1071 can lead to application crashes due to stack overflow caused by improper handling of user-supplied UTF8 strings.