From redhat bugzilla at $URL , and phrack blog (http://www.phrack.org/):
In the Phrack article "A Eulogy for Format Strings", a researcher using
nickname "Captain Planet" reported an integer overflow flaw in the format
string protection mechanism offered by FORTIFY_SOURCE. A remote attacker could
provide a specially crafted executable, leading to FORTIFY_SOURCE format string
protection mechanism bypass, when executed.
Upstream bug and Kees Cook's proposed patches:
this should be fixed once glibc-2.16 is released ... not really planning on back porting before that ...
ChromiumOS has been testing this patch for a while, so i just applied it to our glibc-2.15-r3 as it should be "safe"
(In reply to comment #2)
> ChromiumOS has been testing this patch for a while, so i just applied it to
> our glibc-2.15-r3 as it should be "safe"
So we will stabilize 2.15-r3 or 2.16 ?
considering people are dragging their heels on 2.16, we'll have to stabilize 2.15-r3 first
(In reply to comment #4)
> considering people are dragging their heels on 2.16, we'll have to stabilize
> 2.15-r3 first
Ok, fixed the summary. Do you plan to wait a bit before stabilize?
(In reply to comment #5)
i think the normal ~30 days is fine
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
stable ppc ppc64 with a complete emerge -e @system
stable on arm with complete emerge -e @system
i've marked alpha/ia64/s390 stable, and listed -hppa since that isn't going to get fixed any time soon (waiting on upstream)
sparc stable and sh can't do due to bug 415591
Adding to existing GLSA request.
Integer overflow in the vfprintf function in stdio-common/vfprintf.c in
glibc 2.14 and other versions allows context-dependent attackers to bypass
the FORTIFY_SOURCE protection mechanism, conduct format string attacks, and
write to arbitrary memory via a large number of arguments.
@maintainers: please clean affected versions so we can ship the GLSA.
Affected versions will not be removed so go ahead.
If we must.
This issue was resolved and addressed in
GLSA 201312-01 at http://security.gentoo.org/glsa/glsa-201312-01.xml
by GLSA coordinator Chris Reffett (creffett).