It was found that uloc_acceptLanguageFromHTTP function in common/uloc.cpp does not ensure that there is a '\0' character at the end of a certain temporary array that leads to out of bounds access, possibly causing DoS. CVE assignment: http://seclists.org/oss-sec/2016/q3/137
Created mingw-icu tracking bugs for this issue: Affects: fedora-all [bug 1360341] Affects: epel-7 [bug 1360342]
Created icu tracking bugs for this issue: Affects: fedora-all [bug 1360340]
And the patch fixing this is ... where?
Any update on this?
I don't even find a bug filed in the icu bug tracker upstream: http://bugs.icu-project.org/trac/search?q=CVE-2016-6293 However, at https://sourceforge.net/p/icu/mailman/message/35305922/ upstream say they "are tracking this issue" Maybe they have a private ticket in trac for a publicly-disclosed vulnerability?
It looks like the patch is http://bugs.icu-project.org/trac/changeset/39109 - referenced ticket is private but description, timeline and tests look correct.
Impact here looks relatively low: - a string of the precise length fails to be null terminated, causing out-of-bounds read in strcmp(). At worst this is a crash. - other than php, no packages shipped in Red Hat Enterprise Linux use this function Third-party code can protect itself in the same way as PHP, by ensuring the httpAcceptLanguage parameter passed to uloc_acceptLanguageFromHTTP is no longer than ULOC_FULLNAME_CAPACITY bytes. This constant is defined as 157 in libicu-50.1.2, which is more than enough for a legitimate Accept-Language string. libicu does not make any internal calls to uloc_acceptLanguageFromHTTP, so a simple grep for that entry point is sufficient to determine if client code is vulnerable.
Upstream bug (ICU) (private as at 2016-11-04): http://bugs.icu-project.org/trac/ticket/12652