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

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
--
critical
RESOLVED WORKSFORME
4 years ago
a year ago

People

(Reporter: high.grammar, Unassigned)

Tracking

({crash, reproducible, testcase})

26 Branch
x86_64
Windows 7
crash, reproducible, testcase
Points:
---

Firefox Tracking Flags

(firefox49 affected, firefox-esr45 affected, firefox50 affected, firefox51 affected)

Details

(crash signature)

(Reporter)

Description

4 years ago
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=????????
(Reporter)

Updated

4 years ago
Component: Untriaged → Security

Updated

4 years ago
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

Comment 2

4 years ago
I ran the code in the Scrachpad to crash Firefox.

Comment 3

4 years ago
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

Comment 5

4 years ago
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 '...').

Updated

2 years ago
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
Last Resolved: 2 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.