An issue was discovered in International Components for Unicode (ICU) for C/C++ through 66.1. An integer overflow, leading to a heap-based buffer overflow, exists in the UnicodeString::doAppend() function in common/unistr.cpp.

International Components for Unicode (ICU) for C/C++ 63.1 has an integer overflow in number::impl::DecimalQuantity::toScientificString() in i18n/numberdecimalquantity.cpp.

The ucnvUTF8FromUTF8 function in ucnvu8.cpp in International Components for Unicode (ICU) for C/C++ through 60.1 mishandles ucnvconvertEx calls for UTF-8 to UTF-8 conversion, which allows remote attackers to cause a denial of service (stack-based buffer overflow and application crash) or possibly have unspecified other impact via a crafted string, as demonstrated by ZNC.

An integer overflow flaw was found in the ICU component of the Chromium browser.

Upstream bug(s):

https://code.google.com/p/chromium/issues/detail?id=774382

External References:

https://chromereleases.googleblog.com/2017/12/stable-channel-update-for-desktop.html

Double free in i18n/zonemeta.cpp in International Components for Unicode (ICU) for C/C++ through 59.1 allows remote attackers to execute arbitrary code via a crafted string, aka a "redundant UVector entry clean up function call" issue.

A stack buffer overflow in NumberingSystem in International Components for Unicode (ICU) for C/C++ before 60.2, as used in V8 in Google Chrome prior to 62.0.3202.75 and other products, allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

ICU could allow a remote attacker to execute arbitrary code on the system, caused by improper size limit checks when handling regular expressions. An attacker could exploit this vulnerability using specially crafted data to execute arbitrary code on the system with elevated privileges or cause the application using ICU to crash.

International Components for Unicode (ICU) for C/C++ before 2017-02-13 has an out-of-bounds write caused by a heap-based buffer overflow related to the utf8TextAccess function in common/utext.cpp and the utextsetNativeIndex function.

International Components for Unicode (ICU) for C/C++ before 2017-02-13 has an out-of-bounds write caused by a heap-based buffer overflow related to the utf8TextAccess function in common/utext.cpp and the utextmoveIndex32 function.

A locale string of more than 255 characters passed to ulocgetDisplayName() could overflow a buffer on the stack, leading a crash or, potentially, code execution.

Upstream patch:

http://bugs.icu-project.org/trac/changeset/35699

Upstream issue (private as at 2016-10-11):

http://bugs.icu-project.org/trac/ticket/10891

International Components for Unicode (ICU) is vulnerable to a stack-based buffer overflow, caused by improper bounds checking by the Locale class in common/locid.cpp. By sending an overly long string, a remote attacker could overflow a buffer and execute arbitrary code on the system or cause the application to crash.

The ulocacceptLanguageFromHTTP function in common/uloc.cpp in International Components for Unicode (ICU) through 57.1 for C/C++ does not ensure that there is a '\0' character at the end of a certain temporary array, which allows remote attackers to cause a denial of service (out-of-bounds read) or possibly have unspecified other impact via a call with a long httpAcceptLanguage argument.

Unspecified vulnerability in International Components for Unicode (ICU) before 53.1.0, as used in Apple OS X before 10.11 and watchOS before 2, has unknown impact and attack vectors.

The resolveImplicitLevels function in common/ubidi.c in the Unicode Bidirectional Algorithm implementation in ICU4C in International Components for Unicode (ICU) before 55.1 does not properly track directionally isolated pieces of text, which allows remote attackers to cause a denial of service (heap-based buffer overflow) or possibly execute arbitrary code via crafted text.

The resolveImplicitLevels function in common/ubidi.c in the Unicode Bidirectional Algorithm implementation in ICU4C in International Components for Unicode (ICU) before 55.1 uses an integer data type that is inconsistent with a header file, which allows remote attackers to cause a denial of service (incorrect malloc followed by invalid free) or possibly execute arbitrary code via crafted text.

The Regular Expressions package in International Components for Unicode (ICU) 52 before SVN revision 292944, as used in Google Chrome before 40.0.2214.91, allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via vectors related to a look-behind expression.

The Regular Expressions package in International Components for Unicode (ICU) 52 before SVN revision 292944, as used in Google Chrome before 40.0.2214.91, allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via vectors related to a zero-length quantifier.

The collator implementation in i18n/ucol.cpp in International Components for Unicode (ICU) 52 through SVN revision 293126, as used in Google Chrome before 40.0.2214.91, does not initialize memory for a data structure, which allows remote attackers to cause a denial of service or possibly have unspecified other impact via a crafted character sequence.

International Components for Unicode is vulnerable to a stack-based buffer overflow, caused by improper bounds checking by the canonicalize( ) function. By supplying a negative len value, a remote attacker could overflow a buffer and execute arbitrary code on the system or cause the application to crash.

Heap-based buffer overflow in the doInterval function in regexcmp.cpp in libicu in International Components for Unicode (ICU) 3.8.1 and earlier allows context-dependent attackers to cause a denial of service (memory consumption) and possibly have unspecified other impact via a regular expression that writes a large amount of data to the backtracking stack. NOTE: some of these details are obtained from third party information.

libicu in International Components for Unicode (ICU) 3.8.1 and earlier attempts to process backreferences to the nonexistent capture group zero (aka \0), which might allow context-dependent attackers to read from, or write to, out-of-bounds memory locations, related to corruption of REStackFrames.