Closed Bug 835696 Opened 7 years ago Closed 6 years ago
Permacrash on android-noion on b2g18 - jsreftest
.html?test=ecma _3/Reg Exp/regress-119909 .js | application crashed [@ JSC::Yarr::Yarr Generator::op Compile Alternative]
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 126.96.36.199-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
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.
This is a possibly exploitable crash, we need to triage before we make a blocking call.
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?
(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.
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.
6 years ago
Sean, is this a likely dupe of bug 616491?
Based on the failing function and the crash address, yes, this is probably a dupe of Bug 616491.
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.