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.
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:
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
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):