New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 445075 link

Starred by 9 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Apr 2015
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

stack smashing on parsing some symbols

Reported by, Dec 24 2014

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0

Steps to reproduce the problem:
1. open page contains for example ।

What is the expected behavior?
pages must not crashes

What went wrong?
chromium crashes

Crashed report ID: no

How much crashed? Just one tab

Is it a problem with a plugin? No 

Did this work before? Yes 39.0.2171.95

Chrome version: 39.0.2171.95  Channel: stable
OS Version: 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC 2014 x86_64 GNU/Linux
Flash Version: no flash
45.6 KB View Download

Comment 1 by, Dec 24 2014

may be useful file too
480 bytes View Download

Comment 2 by, Dec 24 2014

and this 
I'm not chrome-debug-poweruser, sorry
108 KB View Download
Labels: Needs-Feedback
neiolit0@ : Thank you for the issue, would you mind helping us with the detailed steps to reproduce the crash if its a consistent one to further triage it.
Can you please provide crash id, can be found under chrome://crashes(type it in the chrome browser).

Comment 4 by, Dec 26 2014

There are no steps, just browse page that contains crash-symbols (like
U+FEFF) and Chromium crashs automatically. Also, "Crash reporting is not
available in Chromium.", but Chrome not crashes. That's all I know.

Comment 5 Deleted

Comment 6 by, Dec 26 2014

Sorry, not U+FEFF but exactly U+0964 and U+0965 (and may be some else from
this block
I'm having the same issue. I'm on Arch Linux as well. Same kernel, same Chromium build as OP. I was actually looking for a list of unicode characters on Wikipedia but the article is consistently crashing my tab:

Related articles and websites are crashing as well.

For some reason, even visiting this issue is crashing Chromium, even though I don't see any obvious unicode characters in the comments.

If you need a quick check:
It's a websearch for U+0964 which consistently crashes the opening tab.
I think this has something to do with the recent xorg-fonts-misc update in Arch.

Comment 9 by, Jan 4 2015

but the other apps don't crash
This appears to be caused by a buffer overflow in blink::HarfBuzzShaper::resolveCandidateRuns() which is triggered by the new scripts added in Unicode 7.0 and ICU 54.1.

In Arch Linux we compile Chromium with: -fstack-protector-strong --param=ssp-buffer-size=4. This adds a stack canary to createHarfBuzzRuns() which gets overwritten when resolveCandidateRuns() calls ICU's uscript_getScriptExtensions() with what seems to be an incorrect "capacity" value.

The relevant code in resolveCandidateRuns() is:

UScriptCode scriptExtensions[8];
    int extensionsLength = uscript_getScriptExtensions(run.character,
        scriptExtensions, sizeof(scriptExtensions), &errorCode);
(above code is located in third_party/WebKit/Source/platform/fonts/harfbuzz/HarfBuzzShaper.cpp)

So a value of 32 is passed as the capacity parameter, instead of the correct value which is 8.

Replacing "sizeof(scriptExtensions)" with "8" fixes the issue in my test builds of Chromium 39.0.2171.95, but something like "sizeof(scriptExtensions) / sizeof(scriptExtensions[0])" might be preferable. Since I'm not familiar with ICU and/or Unicode, I don't know if scriptExtensions needs to be expanded to 16 elements (or more), in addition to passing the correct "capacity" value.

The issue is 100% reproducible with the following software versions:

- Chromium 39.0.2171.95 (also 41.0.2251.0)
- ICU 54.1
- GCC 4.9.2
- glibc 2.20

I've attached a backtrace taken right after the stack canary is overwritten.

Finally, I also checked the return value of uscript_getScriptExtensions() for U+0964 with different versions of ICU:

ICU 52.1: 5
ICU 53.1: 5
ICU 54.1: 16

ICU 52.1 and 53.1 write the following to scriptExtensions:


While ICU 54.1 includes many more:

59.0 KB View Download
Project Member

Comment 12 by, Jan 26 2015

The following revision refers to this bug:

r188995 | | 2015-01-26T23:01:06.765452Z

Changed paths:

Fix a buffer overflow in blink::HarfBuzzShaper::resolveCandidateRuns()

The capacity value passed to uscript_getScriptExtensions() is
incorrectly calculated as sizeof(scriptExtensions). This results in a
buffer overflow when ICU returns more than 8 script codes.

Fix the above issue by correctly passing the number of elements the
scriptExtensions array can hold as the capacity parameter.

Additionally, expand the scriptExtensions array to USCRIPT_CODE_LIMIT
elements, to account for extra script codes returned by ICU 54.1.

Note: USCRIPT_CODE_LIMIT is probably much larger than the maximum number
      of scripts that ICU will return. For example, ICU 54.1 specifies
      USCRIPT_CODE_LIMIT to be 167, while the maximum value returned by
      uscript_getScriptExtensions() is 17 (for code points in 0..0x10ffff).

      We could use a much smaller array, but in the case it becomes
      insufficient in the future, the U_BUFFER_OVERFLOW_ERROR error
      returned by ICU would be silently ignored.

BUG= 445075 

Review URL:
Tested the same on Linux 14.04 chrome version 42.0.2311.14 - Navigated to the below sites

No crash is observed

Please let me know if i am missing something in verifying the fix.
@eae, Could you please change the status of the bug accordingly
You're probably missing ICU 54.1. Earlier versions didn't return enough script codes to overflow the 8-element array.

Comment 15 by, Mar 26 2015

 Issue 437668  has been merged into this issue.

Comment 16 by, Mar 26 2015

Shouldn't this be marked fixed?
Yes, Chromium 42 will contain the fix.
Chromium 42 is released.  Can anyone confirm the fix?
Yes, it's fixed; Chromium 42 contains the patch and works fine with ICU up to and including version 55.1.
Labels: M-42
Status: Fixed
Thank you for the confirmation (and fixing the bug).  Marking as fixed per comment #19.

Sign in to add a comment