Closed Bug 835696 Opened 7 years ago Closed 6 years ago

Permacrash on android-noion on b2g18 - jsreftest.html?test=ecma_3/RegExp/regress-119909.js | application crashed [@ JSC::Yarr::YarrGenerator::opCompileAlternative]

Categories

(Core :: JavaScript Engine, defect, critical)

ARM
Android
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 616491
Tracking Status
b2g18 --- wontfix
b2g18-v1.0.1 --- wontfix

People

(Reporter: philor, Assigned: dvander)

References

Details

(Keywords: crash, csectype-dos, intermittent-failure, Whiteboard: stack-exhaustion?)

Crash Data

We a) finally remembered that b2g18 should be running jsreftests on android-noion, and b) finally figured out why the patch to run them wasn't working, and...

https://tbpl.mozilla.org/php/getParsedLog.php?id=19224020&tree=Mozilla-B2g18
https://tbpl.mozilla.org/php/getParsedLog.php?id=19224675&tree=Mozilla-B2g18
Android no-ionmonkey Tegra 250 mozilla-b2g18 opt test jsreftest-2 on 2013-01-28 21:37:37 PST for push b9871d06ba06
slave: tegra-173

REFTEST TEST-START | http://10.250.48.219:30173/jsreftest/tests/jsreftest.html?test=ecma_3/RegExp/regress-119909.js | 183 / 969 (18%)

INFO | automation.py | Application ran for: 0:01:59.866018
INFO | automation.py | Reading PID log: /tmp/tmplMFbr1pidlog
getting files in '/mnt/sdcard/tests/reftest/profile/minidumps/'
Downloading symbols from: http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-b2g18-android-noion/1359434992/fennec-18.0.en-US.android-arm.crashreporter-symbols.zip
PROCESS-CRASH | http://10.250.48.219:30173/jsreftest/tests/jsreftest.html?test=ecma_3/RegExp/regress-119909.js | application crashed [@ JSC::Yarr::YarrGenerator::opCompileAlternative]
Crash dump filename: /tmp/tmpaaAVpV/34ac9ec6-3938-221d-34573caa-2a8b17bc.dmp
Operating system: Android
                  0.0.0 Linux 2.6.32.9-00002-gd8084dc-dirty #1 SMP PREEMPT Wed Feb 2 11:32:06 PST 2011 armv7l nvidia/harmony/harmony/harmony:2.2/FRF91/20110202.102810:eng/test-keys
CPU: arm
     0 CPUs

Crash reason:  SIGSEGV
Crash address: 0x44a08708

Thread 4 (crashed)
 0  libxul.so!JSC::Yarr::YarrGenerator::opCompileAlternative [YarrJIT.cpp : 2218 + 0x2]
     r4 = 0x44b05bd0    r5 = 0x44a09658    r6 = 0x44a098b0    r7 = 0x00000000
     r8 = 0x44a095e0    r9 = 0x44b06b40   r10 = 0x542203a0    fp = 0x56705af0
     sp = 0x44a086d0    lr = 0x552df34d    pc = 0x552de7b0
    Found by: given as instruction pointer in context
blocking-b2g: --- → tef?
tracking-b2g18: --- → ?
While we definitely need those tests enabled and running, this bug is not a v1.0 release blocker but hopefully David can look into this crash and provide some information on options for follow-up fix.
Assignee: general → dvander
blocking-b2g: tef? → -
This is a possibly exploitable crash, we need to triage before we make a blocking call.
Group: core-security
blocking-b2g: - → tef?
If you're going to hide the bug to star it, you might want to disable running the test, so you don't have a bar of unstarred orange running down your tbpl pointing the way to an exploitable crash (or, if anyone actually tries to star, a string of duplicate open bugs pointing at this bug).
Dave, can you get this assigned quickly? Looks like we want to fix this right away.
Yes, please disable the test for now.
Won't block ship on this but we'll happily take a patch.
blocking-b2g: tef? → -
Restoring the b2g18 affected status: we disabled the test but not the "feature" (the JS engine) that has this bug, which is potentially a security problem.

Gary, Christian: how's the ARM JS fuzzing going? do the generated testcases do anything like what this test was doing?
My guess is that this is bug 616491, since the test crashing here creates a huge number of regex groups and the signature is well known to me from similar desktop crashes. This bug isn't ARM specific, but I assume that we do have less stack space available on B2G and therefore the test fails there while it still works on desktop platforms.

Overall not a security problem as this stack space exhaustion is not exploitable.
Any idea why we aren't seeing this crash on m-c/inbound?
(In reply to Ryan VanderMeulen from comment #14)
> Any idea why we aren't seeing this crash on m-c/inbound?

Do you mean on b2g devices with m-c/inbound? If so, then I don't know, but any changes that increase/decrease the overall stack space usage could trigger this or make it go away again, if the test is almost at its limit on that platform.
(In reply to Christian Holler (:decoder) from comment #15)
> (In reply to Ryan VanderMeulen from comment #14)
> > Any idea why we aren't seeing this crash on m-c/inbound?
> 
> Do you mean on b2g devices with m-c/inbound?

On android-no-ion on TBPL on trunk.
Of course, the obvious possibility is that this was fixed by the Yarr update in bug 740015, which landed for Gecko 19.
Please don't minus this again without consulting the security team.

If this is an exploitable crash, then because content can control regexps that are run in the b2g process, it may be a root privilege escalation from an unprivileged process.  We need to understand the extent of the problem here.
blocking-b2g: - → tef?
(In reply to Ryan VanderMeulen from comment #17)
> Of course, the obvious possibility is that this was fixed by the Yarr update
> in bug 740015, which landed for Gecko 19.

The Yarr update introduced problems of its own - see bug 808478 and bug 824856 for examples.
Is dvander on the hook to determine if this is an exploitable crash, and what the security rating is?
Flags: needinfo?(dvander)
(In reply to Gary Kwong [:gkw] from comment #20)
> The Yarr update introduced problems of its own - see bug 808478 and bug
> 824856 for examples.

I certainly wasn't trying to advocate landing the Yarr update on the b2g18 branch. Just pointing to it as a prime candidate for what fixed it.
My gut feeling is that it's not exploitable, but we should make sure. TBPL doesn't really have any useful information - Marty, would it be possible to get a full callstack here?
Flags: needinfo?(dvander) → needinfo?(mrosenberg)
Just pinged Marty in email.
If this is the same as bug 616491 then it's not exploitable, but bug 616491 is still open so was not fixed by the YARR landing mentioned in comment 17. We need more info to make the call.
Batch edit: Bugs marked status-b2g18: affected after 2/13 branching of v1.0.1 are now also status-b2g18-v1.0.1: affected
We wouldn't block on this, it's confidential and still needs more investigation.
blocking-b2g: tef? → -
(In reply to Chris Jones [:cjones] [:warhammer] from comment #19)
> Please don't minus this again without consulting the security team.

(In reply to Lukas Blakk [:lsblakk] from comment #27)
> We wouldn't block on this, it's confidential and still needs more
> investigation.

...?
Christian: do you test regexp in your ARM JS fuzzer?
Marty did you guys get a chance to get a full call stack?
(In reply to Daniel Veditz [:dveditz] from comment #29)
> Christian: do you test regexp in your ARM JS fuzzer?

Through the regular JS fuzzing, yes. However, for this bug, all we need is a full stack trace including a peak on the pc register to judge what's going on. I'm still confident that this is the stack exhaustion we've been seeing on x86 as well.
Crash Signature: [@ JSC::Yarr::YarrGenerator::opCompileAlternative]
Depends on: 616491
Keywords: csec-dos
Whiteboard: stack-exhaustion?
Can we an update here on the testcase-wanted request?

This is currently showing up as 2nd level of urgency for quality support, so I'd like to get the work done here to be able to pull the keyword or resolve the bug.
Nothing actionable here and no response. Removing from tracking to pull this off our queries.
blocking-b2g: - → ---
tracking-b2g18: + → ---
Group: core-security
Flags: needinfo?(mrosenberg)
Sean, is this a likely dupe of bug 616491?
Flags: needinfo?(sstangl)
Based on the failing function and the crash address, yes, this is probably a dupe of Bug 616491.
Flags: needinfo?(sstangl)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 616491
You may wish to pull the fix from Bug 616491 into some B2G repo, though...
Realistically, b2g18 and b2g26 are probably wontfix at this point. Probably wouldn't hurt to get bug 616491 on aurora/beta/b2g28 (and maybe esr24) though. Might as well nominate it for approval.
(In reply to Sean Stangl [:sstangl] from comment #37)
> You may wish to pull the fix from Bug 616491 into some B2G repo, though...

I nominated flags in that bug. You'd have to fill out the flag approval questionaires first.
You need to log in before you can comment on or make changes to this bug.