From the upstream bug at $URL:
len can be greater than nameCapacity here: http://bugs.icu-project.org/trac/browser/icu/trunk/source/common/uloc.cpp#L1808
It also looks possible for len to be zero here and a few lines above.
Fixed in ICU 49.1, which will be unmasked after testing.
I have removed the mask. However, www-client/chromium still depends on <dev-libs/icu-49.
(In reply to comment #2)
> I have removed the mask. However, www-client/chromium still depends on
Thank you. I believe we only need bug 410777 resolved before removing <=dev-libs/icu-49.
Shall we stabilize =dev-libs/icu-49.1 or =dev-libs/icu-49.1.1?
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
(In reply to comment #6)
> amd64 ok
Just to explain, Maurizio compiled all icu RDEPEND and the 'ok' is related to all packages, apart chromium.
No need to have arches in CC list since there is no fix atm for chromium. They will be re-added in the future.
(In reply to comment #8)
> No need to have arches in CC list since there is no fix atm for chromium.
> They will be re-added in the future.
Given the lack of movement in chromium upstream, I think we have 2 options here:
1. Backport the security fix to icu-4.8.
2. Switch chromium to use the bundled copy of ICU, which should have the fix.
(In reply to comment #9)
> 2. Switch chromium to use the bundled copy of ICU, which should have the fix.
It does. We can do that easily, just waiting for decision by maintainers or the security team.
Arches please test and mark stable:
Note that bug #414271 is hppa-specific. Maintainers, you may need to backport the fix to 4.8 "branch" and use that as stable hppa target.
I'm confused. Is there something for us to stabilize in here?
amd64 ok =dev-libs/icu-18.104.22.168-r1
Stable on alpha.
FYI, new libreoffice binpackages have been uploaded which use icu-49. These need stabilization too (amd64, x86), see also bug 411449
Stable for HPPA.
Thanks, everyone. GLSA draft filed.
Stack-based buffer overflow in the _canonicalize function in common/uloc.c
in International Components for Unicode (ICU) before 49.1 allows remote
attackers to execute arbitrary code via a crafted locale ID that is not
properly handled during variant canonicalization.
This issue was resolved and addressed in
GLSA 201209-07 at http://security.gentoo.org/glsa/glsa-201209-07.xml
by GLSA coordinator Sean Amoss (ackle).