1910083 - Crash [@ v8::internal::IrregexpInterpreter::Result v8::internal::(anonymous namespace)::RawMatch] or Assertion failure: base::IsInRange(current, 0, subject.length()), at irregexp/imported/regexp-interpreter.cc:559

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20240726-69a2460cfcb3 (opt build, run with --fuzzing-safe --no-threads):

r=RegExp("((())\\b|()\u1ffC{2})+","i");
r.test()

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x000055555703f554 in v8::internal::IrregexpInterpreter::Result v8::internal::(anonymous namespace)::RawMatch<unsigned char>(v8::internal::Isolate*, v8::internal::Tagged<v8::internal::ByteArray>, v8::internal::Tagged<v8::internal::String>, v8::base::Vector<unsigned char const>, int*, int, int, int, unsigned int, v8::internal::RegExp::CallOrigin, unsigned int) ()
#1  0x000055555701bd56 in js::irregexp::Execute(JSContext*, JS::MutableHandle<js::RegExpShared*>, JS::Handle<JSLinearString*>, unsigned long, js::VectorMatchPairs*) ()
#2  0x0000555556fdb5f5 in js::RegExpShared::execute(JSContext*, JS::MutableHandle<js::RegExpShared*>, JS::Handle<JSLinearString*>, unsigned long, js::VectorMatchPairs*) ()
#3  0x000055555700e5c1 in ExecuteRegExp(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSString*>, int, js::VectorMatchPairs*) ()
#4  0x00005555570202b4 in js::RegExpBuiltinExec(JSContext*, JS::Handle<js::RegExpObject*>, JS::Handle<JSString*>, bool, JS::MutableHandle<JS::Value>) ()
#5  0x0000555556ff52f7 in js::RegExpExec(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSString*>, bool, JS::MutableHandle<JS::Value>) ()
#6  0x0000555556ff50df in bool intrinsic_RegExpExec<true>(JSContext*, unsigned int, JS::Value*) ()
#7  0x0000555556db3e1e in js::Interpret(JSContext*, js::RunState&) ()
#8  0x0000555556da5293 in js::RunScript(JSContext*, js::RunState&) ()
#9  0x0000555556da4d2c in js::Execute(JSContext*, JS::Handle<JSScript*>, JS::Handle<JSObject*>, JS::MutableHandle<JS::Value>) ()
#10 0x0000555556e5a39e in JS_ExecuteScript(JSContext*, JS::Handle<JSScript*>) ()
#11 0x0000555557129e8a in RunFile(JSContext*, char const*, _IO_FILE*, CompileUtf8, bool, bool) ()
#12 0x0000555557128fe8 in Process(JSContext*, char const*, bool, FileKind) ()
#13 0x0000555556b372f7 in main ()
rax	0x24	36
rbx	0x7ffff3e13878	140737285011576
rcx	0xd2c59	863321
rdx	0x55555703f50f	93825020458255
rsi	0x7fffffffbb70	140737488337776
rdi	0x9	9
rbp	0x7fffffffbcb0	140737488338096
rsp	0x7fffffffb9c0	140737488337344
r8	0x354f20f2d3a8	58613971473320
r9	0x555557bfd8d0	93825032771792
r10	0x0	0
r11	0x246	582
r12	0x7a24	31268
r13	0x55555703f527	93825020458279
r14	0x7ffff3e13804	140737285011460
r15	0xd2c5a	863322
rip	0x55555703f554 <v8::internal::IrregexpInterpreter::Result v8::internal::(anonymous namespace)::RawMatch<unsigned char>(v8::internal::Isolate*, v8::internal::Tagged<v8::internal::ByteArray>, v8::internal::Tagged<v8::internal::String>, v8::base::Vector<unsigned char const>, int*, int, int, int, unsigned int, v8::internal::RegExp::CallOrigin, unsigned int)+2484>
=> 0x55555703f554 <_ZN2v88internal12_GLOBAL__N_18RawMatchIhEENS0_19IrregexpInterpreter6ResultEPNS0_7IsolateENS0_6TaggedINS0_9ByteArrayEEENS7_INS0_6StringEEENS_4base6VectorIKT_EEPiiiijNS0_6RegExp10CallOriginEj+2484>:	movzbl (%r8,%rcx,1),%r10d
   0x55555703f559 <_ZN2v88internal12_GLOBAL__N_18RawMatchIhEENS0_19IrregexpInterpreter6ResultEPNS0_7IsolateENS0_6TaggedINS0_9ByteArrayEEENS7_INS0_6StringEEENS_4base6VectorIKT_EEPiiiijNS0_6RegExp10CallOriginEj+2489>:	jmpq   *(%r9,%rax,8)

This looks like a crash with potential memory corruption in irregexp. I'm surprised to see something like this here, did we upgrade irregexp recently? Note that this might affect all browsers if it turns out to be an actual irregexp issue.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 3

[Jan de Mooij [:jandem]]

(In reply to Christian Holler (:decoder) from comment #0)

This looks like a crash with potential memory corruption in irregexp. I'm surprised to see something like this here, did we upgrade irregexp recently?

Yes, very recently in bug 1909012.

Comment 4

[Christian Holler (:decoder)]

I reported this upstream, as it affects at least Chrome Dev.

Comment 5

[Dan Minor [:dminor]]

Do we want to request that the update be backed out while we wait for an upstream fix?

Comment 6

[Bugmon [:jkratzer for issues]]

Verified bug as reproducible on mozilla-central 20240726035627-69a2460cfcb3.
The bug appears to have been introduced in the following build range:

Start: f69df224cf94429fde633e362d9f118684afa22b (20240725001923)
End: f217b9c8ab652f8f373270af20a1fccea353a72b (20240725003908)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f69df224cf94429fde633e362d9f118684afa22b&tochange=f217b9c8ab652f8f373270af20a1fccea353a72b

Comment 7

[Iain Ireland [:iain]]

I think it would be good to back out bug 1909012.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1909012

Comment 9

[Dan Minor [:dminor]]

I've requested a backout in #sheriffs on matrix.

Comment 10

[Dan Minor [:dminor]]

I'll keep an eye on the upstream bug, so we can coordinate our next irregexp update to include that fix.

Comment 11

[Daniel Veditz [:dveditz]]

Fixed by backout, bug 1909012 comment 9

Comment 12

[Bugmon [:jkratzer for issues]]

Verified bug as fixed on rev mozilla-central 20240731211427-693fe3b405c1.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.