Issue metadata
Sign in to add a comment
|
crashed caused by a READ memory access on different addresses
Reported by
cdsrc2...@gmail.com,
Jan 16 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. open asan flag and build chromium. 2. launch chromium with these flags．> ./chrome --js-flags="--allow-natives-syntax" --no-sandbox ./crash.html (The testcase and crash log are in the attachment.) What is the expected behavior? What went wrong? The browser crashed caused by a READ memory access on a unknown address. "var a = a&a&a&a&a^a&a&a&a&a&a&a...." Seems that different number of variable 'a' result in different addresses.Maybe you can control the address from reading a specific memory. And some addresses just look like ascii strings. ==30281==ERROR: AddressSanitizer: SEGV on unknown address 0x72657473696e ==7983==ERROR: AddressSanitizer: SEGV on unknown address 0x0074756f5f6b It looks like "var a = a&a&a&a&a^a&a&a&a&a&a&a...." lead to a memory reading, and the destination could controlled by the number of 'a'. Did this work before? N/A Chrome version: 57.0.2961.0 Channel: n/a OS Version: Ubuntu 14.04.5 Flash Version:
,
Jan 16 2017
After a quick debugging,we found the crash is caused by this asm code "cmp DWORD PTR [esi+0x3], ebx" in CALL_GENERATED_CODE (v8/src/execution.cc -> Invoke -> CALL_GENERATED_CODE). (gdb) i r ... ebx 0x32489431 ... esi 0x0 ... It seems that esi register can be controlled by the compiled js code.
,
Jan 17 2017
,
Jan 17 2017
Assigning to v8 sheriff to triage.
,
Jan 17 2017
ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=6250161035804672
,
Jan 17 2017
Reassigning to Stability Sheriff, since this is not a ClusterFuzz issue.
,
Jan 18 2017
I can reproduce this issue on version 57.0.2961.0, but it seems to have been fixed in version 57.0.2986.0.
,
Jan 18 2017
,
Jan 18 2017
mythria, it seems like your CL (https://codereview.chromium.org/2594543003) fixed this issue. Is your CL an actual fix, or does it only hide the real cause of this issue?
,
Jan 19 2017
Yes, that cl could be the actual fix. In the testcase %BaselineFunctionOnNextCall is called even before the function was compiled. Before my cl landed, BaselineFunctionOnNextCall would expect that type feedback vector is initialized. Since the function was never compiled, it is never initialized and hence it crashes when accessing type feedback vector. My cl fixes this by changing BaselineFunctionOnNextCall to check if a function is already compiled. If it is not compiled it will request for a compilation before baselining the function.
,
Jan 19 2017
I change the status to fixed in that case.
,
Jan 20 2017
,
Feb 14 2017
Assuming nothing needs to be done here with merges.
,
Apr 28 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 12
,
Dec 3
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 Deleted