718 bytes, text/plain
733.25 KB, text/plain
2.00 KB, patch
|Details | Diff | Splinter Review|
We have been observing the following crash signature during monkey runs. [@ mozilla::detail::AtomicBaseIncDec<int, (mozilla::MemoryOrdering)2u>::operator-- | mozilla::dom::BlobParent::IDTableEntry::Release | nsRefPtr<mozilla::dom::BlobParent::IDTableEntry>::~nsRefPtr | mozilla::dom::BlobParent::~BlobParent ] STR not availiable. Cafbot will upload the minidump shortly.
What branch is this based on?
Whiteboard: [caf priority: p1][CR 782853] → [b2g-crash][caf-crash 442][caf priority: p1][CR 782853]
(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #3) > What branch is this based on? This is v2.2. The last crash we saw was with Gaia: http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=69ac77cfa938fae2763ac426a80ca6e5feb6ad25 Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=16a3a81985429f9831283b38a1d79af3a741dedb
4 years ago
Ugh, IPDL automatically destroys actors if the constructor message fails, so we're double-deleting at the moment...
Assignee: nobody → bent.mozilla
Status: NEW → ASSIGNED
Attachment #8551430 - Flags: review?(khuey)
Looks like this was introduces in bug 994190.
This should be rare though... It requires a child process to die at just the right moment before sending one of these messages.
Attachment #8551430 - Flags: review?(khuey) → review+
Comment on attachment 8551430 [details] [diff] [review] Patch, v1 [Security approval request comment] How easily could an exploit be constructed based on the patch? Hard, requires narrow timing between child process crash and parent process message being sent Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? No, but the changes to the code make the problem pretty obvious... Which older supported branches are affected by this flaw? See flags If not all supported branches, which bug introduced the flaw? See above Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? Should be identical for all branches How likely is this patch to cause regressions; how much testing does it need? This is an obviously correct fix, I don't expect any regressions.
Attachment #8551430 - Flags: sec-approval?
ni for Bhavana at her request.
Duplicate of this bug: 1123853
Comment on attachment 8551430 [details] [diff] [review] Patch, v1 sec-approval+ for trunk. Please make and nominate patches for affected branches.
Attachment #8551430 - Flags: sec-approval? → sec-approval+
Comment on attachment 8551430 [details] [diff] [review] Patch, v1 Approval Request Comment (See above)
This was merged to m-c: https://hg.mozilla.org/mozilla-central/rev/8bab67d1c792 https://hg.mozilla.org/releases/mozilla-aurora/rev/d947f5f0abca https://hg.mozilla.org/releases/mozilla-beta/rev/508190797a80
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
This bug was reported by codeaurora.org. IMO, we can enable QC confidential group.
Kevin, I don't think this is necessary, there is no confidential information in this bug.
(In reply to Kevin Hu [:khu] from comment #16) > This bug was reported by codeaurora.org. IMO, we can enable QC confidential > group. Just FYI, this group is not really needed in general. QC confidential data has no place on bugzilla.
Could this bug be triggered outside of Firefox OS?
Probably only in e10s mode.
Whiteboard: [b2g-crash][caf-crash 442][caf priority: p1][CR 782853] → [b2g-crash][caf-crash 442][caf priority: p1][CR 782853][adv-main36-]
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.