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 LC_ALL=C). However, this is not the case with glibc versions up to and including 2.12.1:
LANG=' rm -rf /' locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG= rm -rf /
LC_CTYPE=" rm -rf /"
LC_NUMERIC=" rm -rf /"
LC_TIME=" rm -rf /"
LC_COLLATE=" rm -rf /"
LC_MONETARY=" rm -rf /"
LC_MESSAGES=" rm -rf /"
LC_PAPER=" rm -rf /"
LC_NAME=" rm -rf /"
LC_ADDRESS=" rm -rf /"
LC_TELEPHONE=" rm -rf /"
LC_MEASUREMENT=" rm -rf /"
LC_IDENTIFICATION=" rm -rf /"
LC_ALL=
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/show_bug.cgi?id=330923
[2] http://sources.redhat.com/bugzilla/show_bug.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

Is there any real world example where this bug actually allows crossing trust boundary? I was not able to find any use where this "eval $(locale)" pattern is used even with trusted environment. Additionally, glibc locale man page does not document POSIX requirement to have the output safe for re-entry to the shell.
I don't think this got any CVE assigned either. Gentoo GLSA 201011-01 does link their bug listed in comment #1 as [1], but the issue is not described in the text.
http://www.gentoo.org/security/en/glsa/glsa-201011-01.xml