Crash [@JSC::Yarr::YarrCodeBlock::execute] and Assertion failure: limit >= start, at jsregexpinlines.h:274

RESOLVED DUPLICATE of bug 679986

Status

()

Core
JavaScript Engine
--
critical
RESOLVED DUPLICATE of bug 679986
7 years ago
4 years ago

People

(Reporter: decoder, Assigned: dmandelin)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
x86_64
Linux
assertion, crash, regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox6 unaffected, firefox7 unaffected, status1.9.2 unaffected)

Details

(Whiteboard: [sg:critical?] js-triage-needed, crash signature)

(Reporter)

Description

7 years ago
The following tests crash/assert on mozilla-central revision b7d269a291b6 (no options required). I suspect that it's the same bug:

Crash:

var pattern = "(?:(?:(?:-|)\\s?)|\\w?)*";
var re = new RegExp(pattern);
'8:5-8'.match(re);


Assert:

var pattern =   "(?:(?:)|})*"
var re = new RegExp(pattern);
'8:5-8'.match(re);


As both tests don't involve any back references, I don't think these are duplicates to the previously reported YARR regressions, although the bisect points to the same import revision:

The first bad revision is:
changeset:   70607:cc36a234d0d6
user:        David Mandelin <dmandelin@mozilla.com>
date:        Thu May 12 18:39:47 2011 -0700
summary:     Bug 625600: Update Yarr import to WebKit rev 86639, r=cdleary,dvander


The crash bug does not work on opt32 but the assert was reproduced on a debug32 build as well. I suspect that it affects 32 bit and 64 bit and just the crash test is not reliable across architectures.

Note that this is not a test produced by the RegExp extension of LangFuzz, it was a regular LangFuzz JS mutation. The original test was:

jit-test/tests/basic/bug606882-2.js

I wonder why the RegExp fuzzer did not find this before and will investigate that.

Valgrind trace of the crash:

==39640== Invalid read of size 2
==39640==    at 0x4038113: ???
==39640==    by 0x7A3112: JSC::Yarr::YarrCodeBlock::execute(unsigned short const*, unsigned int, unsigned int, int*) (YarrJIT.h:72)
==39640==    by 0x7A278E: JSC::Yarr::execute(JSC::Yarr::YarrCodeBlock&, unsigned short const*, unsigned int, unsigned int, int*) (YarrJIT.cpp:2439)
==39640==    by 0x443275: js::RegExp::executeInternal(JSContext*, js::RegExpStatics*, JSString*, unsigned long*, bool, js::Value*) (jsregexpinlines.h:369)
==39640==    by 0x4429C3: js::RegExp::execute(JSContext*, js::RegExpStatics*, JSString*, unsigned long*, bool, js::Value*) (jsregexpinlines.h:167)
==39640==    by 0x5DB45F: DoMatch(JSContext*, js::RegExpStatics*, JSString*, RegExpPair const&, bool (*)(JSContext*, js::RegExpStatics*, unsigned long, void*), void*, MatchControlFlags, js::Value*) (jsstr.cpp:1491)
==39640==    by 0x5DB967: str_match(JSContext*, unsigned int, js::Value*) (jsstr.cpp:1566)
==39640==    by 0x525C22: js::CallJSNative(JSContext*, int (*)(JSContext*, unsigned int, js::Value*), js::CallArgs const&) (jscntxtinlines.h:300)
==39640==    by 0x4FD9DE: js::InvokeKernel(JSContext*, js::CallArgs const&, js::MaybeConstruct) (jsinterp.cpp:660)
==39640==    by 0x513889: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsinterp.cpp:4058)
==39640==    by 0x4FD758: js::RunScript(JSContext*, JSScript*, js::StackFrame*) (jsinterp.cpp:614)
==39640==    by 0x4FE219: js::ExecuteKernel(JSContext*, JSScript*, JSObject&, js::Value const&, js::ExecuteType, js::StackFrame*, js::Value*) (jsinterp.cpp:814)
==39640==  Address 0x20410440e is not stack'd, malloc'd or (recently) free'd
Assignee: general → dmandelin
status-firefox7: affected → wontfix
tracking-firefox7: ? → -
(Reporter)

Comment 1

7 years ago
I modified LangFuzz to be able to use the code generator directly, without test mutation. After a few minutes, it revealed this issue with a few more examples:

(?:|[]]?)*
(?:|.+.(?!))*
(?:|\t*?)*


So it seems that all tests start with a non-capturing group with an empty first alternative and that group is quantified.
Blocks: 625600
Keywords: regression
presumably this is a bug in YARR itself. Have you filed a webkit bug for them? (please CC me if you do).
tracking-firefox8: ? → +
tracking-firefox9: ? → +
(Assignee)

Comment 3

7 years ago
Just FYI on these Yarr bugs, they're on my list but I'm going to JSConf.EU this weekend, so they won't get any attention until after I come back.
(Reporter)

Comment 4

7 years ago
The first test from comment 0 (now?) crashes [@ js::RegExp::executeInternal]. Adding this to the list of crash signatures because I've seen several RegExp related crashes in the wild lately. Maybe this helps correlating them to a bug.
Crash Signature: [@ JSC::Yarr::YarrCodeBlock::execute] → [@ JSC::Yarr::YarrCodeBlock::execute] [@ js::RegExp::executeInternal]

Updated

7 years ago
Crash Signature: [@ JSC::Yarr::YarrCodeBlock::execute] [@ js::RegExp::executeInternal] → [@ JSC::Yarr::YarrCodeBlock::execute] [@ js::RegExp::executeInternal] [@ JSC::Yarr::execute(JSC::Yarr::YarrCodeBlock&, wchar_t const*, unsigned int, unsigned int, int*) ]
(Assignee)

Comment 5

7 years ago
Filed https://bugs.webkit.org/show_bug.cgi?id=69987 along with some preliminary tech analysis (nothing terribly interesting from a security point of view, though).
status1.9.2: --- → unaffected
(Assignee)

Comment 6

7 years ago
Fixed by the patch in the other bug, also the key feature is the same (alternative in a *-quantified group matches empty).
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 679986
Clearing flags, this is tracked in the bug this is duped against.
status-firefox7: wontfix → unaffected
status-firefox8: affected → ---
status-firefox9: affected → ---
tracking-firefox7: - → ---
tracking-firefox8: + → ---
tracking-firefox9: + → ---
Group: core-security
You need to log in before you can comment on or make changes to this bug.