Closed Bug 953279 Opened 11 years ago Closed 8 years ago

Invalid pointer write crash on large regexp with lots of quantifiers, followed by a start-of-string assertion

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
26 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox49 --- affected
firefox-esr45 --- affected
firefox50 --- affected
firefox51 --- affected

People

(Reporter: high.grammar, Unassigned)

Details

(Keywords: crash, reproducible, testcase)

Crash Data

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

just run below code.
new RegExp(new Array(500000).join("1*") + "^").exec(1);


Actual results:

(3700.268c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0d800328 ebx=00000031 ecx=00000001 edx=00000001 esi=00000001 edi=0cccc010
eip=29c0005e esp=001f4120 ebp=003dc5a8 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
29c0005e 893424          mov     dword ptr [esp],esi  ss:002b:001f4120=????????
Component: Untriaged → Security
Severity: normal → critical
Crash Signature: [@ js::RegExpShared::execute(JSContext*, wchar_t const*, unsigned int, unsigned int*, js::MatchPairs&) ]
Component: Security → JavaScript Engine
Keywords: crash, reproducible, testcase
Product: Firefox → Core
I ran the code in the Scrachpad to crash Firefox.
It's somewhat nonsensical to have ^ at the end of a component of a RegExp, but it matches the syntax -- resummarizing.  (The "malformed" claim caught my eye, because it would imply a syntax-parsing mistake requiring a SyntaxError be thrown -- without getting into execution at all.)
Summary: invalid pointer write crash on malformed regexp → Invalid pointer write crash on large regexp with lots of quantifiers, followed by a start-of-string assertion
Is this a failure to check for OOM somewhere after using a fallible allocator?
Status: UNCONFIRMED → NEW
Ever confirmed: true
That was going to be my guess, as it executed without error for me on linux64 (albeit without trying to print out the result, via -e '...').
Crash Signature: [@ js::RegExpShared::execute(JSContext*, wchar_t const*, unsigned int, unsigned int*, js::MatchPairs&) ] → [@ js::RegExpShared::execute(JSContext*, wchar_t const*, unsigned int, unsigned int*, js::MatchPairs&) ] [@ js::RegExpShared::execute ]
No longer reproducible, probably fixed when we switched to irregexp (bug 976446). Resolving as WFM.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Crash volume for signature 'js::RegExpShared::execute':
 - nightly (version 52): 0 crashes from 2016-09-19.
 - aurora  (version 51): 2 crashes from 2016-09-19.
 - beta    (version 50): 29 crashes from 2016-09-20.
 - release (version 49): 112 crashes from 2016-09-05.
 - esr     (version 45): 237 crashes from 2016-06-01.

Crash volume on the last weeks (Week N is from 10-03 to 10-09):
            W. N-1  W. N-2
 - nightly       0       0
 - aurora        2       0
 - beta         27       2
 - release      89      23
 - esr          12      14

Affected platforms: Windows, Mac OS X

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly
 - aurora  #1474     #1102
 - beta    #545      #448
 - release #729      #382
 - esr     #631
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox-esr45: --- → affected
You need to log in before you can comment on or make changes to this bug.