Closed Bug 1257921 Opened 8 years ago Closed 2 years ago

crash in mozilla::MozPromise<T>::ThenValueBase::ResolveOrRejectRunnable::ResolveOrRejectRunnable

Categories

(Core :: Audio/Video: Playback, defect, P3)

Product:
Core
Component:
Audio/Video: Playback
Version:
48 Branch
Platform:
x86
Android
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
e10s - ---
firefox45 - wontfix
firefox48 --- wontfix
firefox49 --- wontfix
firefox-esr45 - wontfix
firefox50 + wontfix
firefox51 + wontfix
firefox52 + wontfix
firefox-esr52 - wontfix
firefox-esr60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox73 --- wontfix
firefox89 --- wontfix

People

(Reporter: alex_mayorga, Assigned: alwu)

References

(Depends on 1 open bug)

Details

(4 keywords)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-4423ec35-acc9-4672-938d-589462160318.
=============================================================

Prerequisites?
- Connect to the campus WiFi

Steps:
- Start watching https://www.netflix.com/watch/70279201 at a meeting room
- Pause the video
- Walk up to your cubicle
- Un-pause the video

Result:
All tabs crashed.

Expected result:
Video resumes.

Crashing Thread (39)
Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::MozPromise<bool, nsresult, 0>::ThenValueBase::ResolveOrRejectRunnable::ResolveOrRejectRunnable(mozilla::MozPromise<bool, nsresult, 0>::ThenValueBase*, mozilla::MozPromise<bool, nsresult, 0>*) 	xpcom/threads/MozPromise.h
1 	xul.dll 	mozilla::MozPromise<bool, nsresult, 0>::ThenValueBase::Dispatch(mozilla::MozPromise<bool, nsresult, 0>*) 	xpcom/threads/MozPromise.h
2 	xul.dll 	mozilla::MozPromise<bool, nsresult, 0>::DispatchAll() 	xpcom/threads/MozPromise.h
3 	xul.dll 	mozilla::MozPromise<bool, nsresult, 0>::Private::Resolve<bool&>(bool&, char const*) 	xpcom/threads/MozPromise.h
4 	xul.dll 	mozilla::MozPromiseHolder<mozilla::MozPromise<bool, nsresult, 0> >::Resolve(bool, char const*) 	xpcom/threads/MozPromise.h
5 	xul.dll 	mozilla::media::VideoSink::Stop() 	dom/media/mediasink/VideoSink.cpp
6 	xul.dll 	mozilla::MediaDecoderStateMachine::StopMediaSink() 	dom/media/MediaDecoderStateMachine.cpp
7 	xul.dll 	mozilla::MediaDecoderStateMachine::Reset() 	dom/media/MediaDecoderStateMachine.cpp
8 	xul.dll 	mozilla::MediaDecoderStateMachine::Shutdown() 	dom/media/MediaDecoderStateMachine.cpp
9 	xul.dll 	mozilla::detail::ProxyRunnable<mozilla::MozPromise<bool, bool, 0>, mozilla::MediaDecoderReader>::Run() 	xpcom/threads/MozPromise.h
10 	xul.dll 	mozilla::AutoTaskDispatcher::TaskGroupRunnable::Run() 	xpcom/threads/TaskDispatcher.h
11 	xul.dll 	mozilla::TaskQueue::Runner::Run() 	xpcom/threads/TaskQueue.cpp
12 	xul.dll 	nsThreadPool::Run() 	xpcom/threads/nsThreadPool.cpp
13 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
14 	xul.dll 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp
15 	xul.dll 	mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp
16 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc
17 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc
18 	xul.dll 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp
19 	nss3.dll 	PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c
20 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c
21 	msvcr120.dll 	_callthreadstartex 	f:\dd\vctools\crt\crtw32\startup\threadex.c:376
22 	msvcr120.dll 	_threadstartex 	f:\dd\vctools\crt\crtw32\startup\threadex.c:354
23 	kernel32.dll 	BaseThreadInitThunk 	
24 	ntdll.dll 	RtlUserThreadStart 	
25 	kernel32.dll 	BasepReportFault 	
26 	kernel32.dll 	BasepReportFault
[Tracking Requested - why for this release]:
blocking-b2g: --- → 2.2r?
tracking-b2g: --- → backlog
[Tracking Requested - why for this release]:
status-firefox45: --- → ?
status-firefox48: affected → ?
tracking-e10s: --- → ?
tracking-firefox45: --- → ?
I'll see if I can reproduce.
Flags: needinfo?(twalker)
I haven't been able to reproduce this. Also there are no recent (past 7 days)  reports of this in crash stats. All but 2 of the reports (which are on 46 beta) are on 45.0.*.  As such this isn't an e10s bug. A memory of some sort bug, as almost off the signatures have EXCEPTION_ACCESS_VIOLATION_WRITE 0xffffffffe5e5e5e9
tracking-e10s: ? → -
Flags: needinfo?(twalker)
Component: Audio/Video → Audio/Video: Playback
4 crashes in the last 28 days.
Priority: -- → P2
Mass change P2 -> P3
Priority: P2 → P3
According to bug 1283823 comment 26, this (address is almost always 0xffffffffe5e5e5e9) should be a sec-high.
Group: media-core-security
Crash Signature: [@ mozilla::MozPromise<T>::ThenValueBase::ResolveOrRejectRunnable::ResolveOrRejectRunnable] → [@ mozilla::MozPromise<T>::ThenValueBase::ResolveOrRejectRunnable::ResolveOrRejectRunnable] [@ nsRefPtr<T>::nsRefPtr<T> | mozilla::MozPromise<T>::ThenValueBase::ResolveOrRejectRunnable::ResolveOrRejectRunnable ] [@ RefPtr<T>::RefPtr<T> | mozilla::MozPro…
status-firefox49: --- → affected
status-firefox50: --- → affected
Flags: needinfo?(dveditz)
(In reply to Daniel Veditz [:dveditz] from comment #8)
> The main signature seems to be
> https://crash-stats.mozilla.com/signature/
> ?signature=RefPtr%3CT%3E%3A%3ARefPtr%3CT%3E%20|%20mozilla%3A%3AMozPromise%3CT
> %3E%3A%3AThenValueBase%3A%3AResolveOrRejectRunnable%3A%3AResolveOrRejectRunna
> ble

I don't see this signature in after 49.

JW - do you know of anything that may have fixed this bug?
Flags: needinfo?(jwwang)
Priority: P3 → P1
Per comment 10, the crash is still happening in low rate.
Flags: needinfo?(jwwang)
All crashes seem to be on Windows
OS: Windows 7 → Windows
Bobby/JYA/Gerald - can one or more of you look at this?  it's a persistent sec-high UAF in the MozPromise code... Something isn't holding a ref I'd guess.  It's down in Dispatch() before it crashes from what I see.

Note: bobby may be busy, so perhaps jya/gerald should look.
Flags: needinfo?(jyavenard)
Flags: needinfo?(gsquelart)
Flags: needinfo?(bobbyholley)
I don't have cycles for media. I'd be surprised if the bug was actually in MozPromise though.
Flags: needinfo?(bobbyholley)
bholley: I expected that.

This appears to be frame 1 (frame 0 is RefPtr::RefPtr):
MozPromise.h:370
      RefPtr<Runnable> runnable =
        static_cast<Runnable*>(new (typename ThenValueBase::ResolveOrRejectRunnable)(this, aPromise));

Since ResolveOrRejectRunnable stores this and aPromise in Maybe<>s, my assumption is that aPromise or this were deallocated before this; which I presume means something either blew its refcount or didn't hold a refcount.  I'd be surprised if it were the 'this', so it must be the aPromise.

Following through with this sort of analysis would at least provide a bounds on what type of error it must be, and whether if could possibly be in MozPromise or not.  (Or if there's any chance it's a "wrong-thread" issue with MozPromise; probably not but worth mentioning).
Wonder if it's related to bug 1315631.

This causes "this" to be deleted in the constructor, if a promise is used / returned on the next call, it's going to crash there.
Flags: needinfo?(jyavenard)
Tracking 52+ for this sec high issue.
tracking-firefox52: ? → +
(In reply to Jean-Yves Avenard [:jya] from comment #16)
> Wonder if it's related to bug 1315631.
> 
> This causes "this" to be deleted in the constructor, if a promise is used /
> returned on the next call, it's going to crash there.

As far as I can tell we're still seeing this signature after the fix for bug 1315631, there are reports from 50.1.0, 45.6.0esr and 51.0b10.
(In reply to Julien Cristau [:jcristau] from comment #18)
> (In reply to Jean-Yves Avenard [:jya] from comment #16)
> > Wonder if it's related to bug 1315631.
> > 
> > This causes "this" to be deleted in the constructor, if a promise is used /
> > returned on the next call, it's going to crash there.
> 
> As far as I can tell we're still seeing this signature after the fix for bug
> 1315631, there are reports from 50.1.0, 45.6.0esr and 51.0b10.

jya, would you expect the bug 1315631 fix to solve this, or were you just indicating the problems may be similar/related?  (I was thinking the latter)
Flags: needinfo?(jyavenard)
Bug 1315631 is fixed in 50+, and we're still getting these crashes (UAF signatures included) in 50 and 51.

jya: gerald:  any other thoughts?  https://crash-stats.mozilla.com/report/index/4286a4a6-4a31-42c5-93d1-8e5292170118 is a reasonable example stack (and UAF), calling Resolve() from MediaTimer::UpdateLocked() (and crashing in RefPtr<mozilla::gfx::SourceSurface>(mozilla::gfx::SourceSurface*))
I think it should be fixed in bug 1319987 which completely changed the way we shut down things, making everything fully asynchronous.
Flags: needinfo?(jyavenard)
Mark 51 won't fix as 51 was released and the volume of 51 is low now.
status-firefox50: affected → wontfix
status-firefox51: affected → wontfix
(In reply to Jean-Yves Avenard [:jya] from comment #21)
> I think it should be fixed in bug 1319987 which completely changed the way
> we shut down things, making everything fully asynchronous.

That doesn't look upliftable.... anything we can do (wallpaper?) for 52/53?
Flags: needinfo?(jyavenard)
The first signature is also different than the others (EXEC crashes in callbacks from the sspeex resampler code for AudioStream....).  jya, would those be fixed as well by the landing on Nightly?
See Also: → 1339677
(In reply to Randell Jesup [:jesup] from comment #23)
> (In reply to Jean-Yves Avenard [:jya] from comment #21)
> > I think it should be fixed in bug 1319987 which completely changed the way
> > we shut down things, making everything fully asynchronous.
> 
> That doesn't look upliftable.... anything we can do (wallpaper?) for 52/53?

jya - any chance we can uplift or wallpaper this in any way for 52/53?
(In reply to Randell Jesup [:jesup] from comment #25)
> (In reply to Randell Jesup [:jesup] from comment #23)
> > (In reply to Jean-Yves Avenard [:jya] from comment #21)
> > > I think it should be fixed in bug 1319987 which completely changed the way
> > > we shut down things, making everything fully asynchronous.
> > 
> > That doesn't look upliftable.... anything we can do (wallpaper?) for 52/53?
> 
> jya - any chance we can uplift or wallpaper this in any way for 52/53?

This is an area in JW's expertise. I'll let him answer..

On second thought, i don't think bug 1319987 will help in any ways. This is in the MediaDecoderStateMachine and VideoSink
Flags: needinfo?(jyavenard)
Flags: needinfo?(jwwang)
Flags: needinfo?(gsquelart)
Sorry, I don't have a theory about this crash. The crash address=0x20000000a doesn't look like a UAF or null-deference at all. Given the volume is quite low, I assume it is some kind of random memory corruption.
Flags: needinfo?(jwwang)
(In reply to JW Wang [:jwwang] [:jw_wang] from comment #27)
> Sorry, I don't have a theory about this crash. The crash address=0x20000000a
> doesn't look like a UAF or null-deference at all. Given the volume is quite
> low, I assume it is some kind of random memory corruption.

Where did you see that crash address?

https://crash-stats.mozilla.com/search/?signature=%3DRefPtr%3CT%3E%3A%3ARefPtr%3CT%3E%20%7C%20mozilla%3A%3AMozPromise%3CT%3E%3A%3AThenValueBase%3A%3AResolveOrRejectRunnable%3A%3AResolveOrRejectRunnable&product=Firefox&version=51.0.1&date=%3E%3D2017-02-16T11%3A07%3A00.000Z&date=%3C2017-02-23T11%3A07%3A00.000Z&_sort=-date&_facets=signature&_facets=address&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-address

> 1 	0xffffffffe5e5e5e9 	3 	75.00 %
> 2 	0x296f4844 	        1 	25.00 %
Flags: needinfo?(jwwang)
The report from comment 0.
Flags: needinfo?(jwwang)
(In reply to JW Wang [:jwwang] [:jw_wang] from comment #29)
> The report from comment 0.

That one is pretty old, we are seeing mainly UAF addresses now.
JW, can we assign you to investigate this further?
Flags: needinfo?(jwwang)
Sure. I will keep monitoring this bug.
Assignee: nobody → jwwang
Flags: needinfo?(jwwang)
[Tracking Requested - why for this release]:

We'd want to uplift any fix to 52esr

(In reply to JW Wang [:jwwang] [:jw_wang] from comment #34)
> Sure. I will keep monitoring this bug.

We now have around 10 crashes on 52esr; several of which are clear UAFs.
status-firefox-esr52: --- → affected
tracking-firefox-esr52: --- → ?
Flags: needinfo?(jwwang)
add51568-d76e-494a-ad60-c91482170316
ca2029d6-a625-4594-949a-6906f2170315

We have 2 crashes with the same stack but different crash addresses which make me believe the memory corruption is caused by some components other than MozPromise.

It should be helpful to uplift bug 1157323 which definitely fixed some memory corruption.
Flags: needinfo?(jwwang)
(In reply to JW Wang [:jwwang] [:jw_wang] from comment #36)
> add51568-d76e-494a-ad60-c91482170316
> ca2029d6-a625-4594-949a-6906f2170315
> 
> We have 2 crashes with the same stack but different crash addresses which
> make me believe the memory corruption is caused by some components other
> than MozPromise.

That's quite possible, of course.

> It should be helpful to uplift bug 1157323 which definitely fixed some
> memory corruption.

That landed in 52, so unless you're referring to 45ESR, I don't know what you mean
(In reply to JW Wang [:jwwang] [:jw_wang] from comment #36)
> add51568-d76e-494a-ad60-c91482170316
> ca2029d6-a625-4594-949a-6906f2170315
> 
> We have 2 crashes with the same stack but different crash addresses which
> make me believe the memory corruption is caused by some components other
> than MozPromise.

JW, do you think this bug is actionable after all? Would be great to get the ball moving again. This is a sec-high after all.
Flags: needinfo?(jwwang)
No, I don't have any idea to progress this bug. However, I do believe this is caused by some memory corruption. See the analysis below.
Assignee: jwwang → nobody
Flags: needinfo?(jwwang)
https://crash-stats.mozilla.com/report/index/999ed5b8-83ef-418a-a04c-e58382170326

Frame 4 called InitPromise::CreateAndResolve() and frame 1 called DispatchAll() and then crashed.
However, for a newly created promise (created by InitPromise::CreateAndResolve()), mThenValues should be empty and it doesn't make sense for |mThenValues[i]->Dispatch(this);| [1] to be called at all.

[1] https://hg.mozilla.org/releases/mozilla-aurora/annotate/36f165ceceba/xpcom/threads/MozPromise.h#l879
Some memory corruption might be attributed to bug 1351053.
Depends on: 1351053
This has drifted, but is still happening.  Bug 1351053 is fixed in 54, and we still get crashes in 54.

A lot come from MediaTimer::UpdateLocked(), but a fair number come from other areas in media if you look at the stacks.

JYA, do you have any ideas?
Flags: needinfo?(jyavenard)
no idea...

looks like memory corruption, the crash rate is very low.

Those crashes all related to a MediaTimer firing.

not sure if I can help there.
Flags: needinfo?(jyavenard)
NI to anthony to find an owner
Flags: needinfo?(ajones)
Bug 1371982 fixed a UAF bug in MozPromise. I will keep an eye on this bug and monitor the crash rate.
Depends on: 1371982
Flags: needinfo?(ajones)
The crash rate is still low, but it doesn't seem to have changed much.
Flags: needinfo?(jwwang)
I have no idea to progress this bug. Those crashes look like random memory corruption.
Flags: needinfo?(jwwang)
Most now seem to be from mozilla::MediaFormatReader::DecoderDataWithPromise::ResolvePromise() - though not all (some are MediaTimer, though most of the 55/56 crashes are FormatReader).

These do not look like random corruption; there was a spike a few days ago, but it *looks* like a single installation repeatedly crashing -- which means not random corruption.  The URL for that person was facebook.  There was an earlier instance of a user repeatedly crashing here on the same URL (not facebook), so something looks like a repeatable failure for a specific set of data and actions.
Flags: needinfo?(jyavenard)
I'd like to track this after bug 1247189 is fixed.

there's a race in there that could lead to memory corruption
Flags: needinfo?(jyavenard)
Depends on: 1247189
Hi Anthony:

I have assigned these security bugs to you to reassign them to appropriate developers in your team to investigate and fix them.

Thanks!

Wennie
Assignee: nobody → ajones
Flags: needinfo?(ajones)
Alastor - can you take this one in conjunction with bug 1247189?
Assignee: ajones → nobody
Flags: needinfo?(ajones) → needinfo?(alwu)
Assignee: nobody → alwu
(In reply to Alastor Wu [:alwu][please needinfo me][GMT+8] from comment #52)
> https://crash-stats.mozilla.com/signature/
> ?signature=mozilla%3A%3AMozPromise%3CT%3E%3A%3AThenValueBase%3A%3AResolveOrRe
> jectRunnable%3A%3AResolveOrRejectRunnable&date=%3E%3D2017-10-26T14%3A46%3A50.
> 000Z&date=%3C2017-11-02T14%3A46%3A50.
> 000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_colum
> ns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-
> date&page=1#reports

Most of them have CDMProxy in the crash stack. I wonder if it has something to do with MSE or the ChrominumCDM.
These are still happening at a reasonable rate even in 58 etc. JW, can you investigate?
Flags: needinfo?(jwwang)
I will keep an eye on this bug, but I don't have a clear idea how to progress this bug.

https://crash-stats.mozilla.com/report/index/8c55d937-b210-4801-a3d0-bc22e0171229#allthreads

This one looks like a UAF and any memory bug in the whole media stack could result in this. Since media code is the most heavy user of MozPromise, it is not a surprise that most crash stacks involve media objects.
Flags: needinfo?(jwwang)
Could this be related to the other bug we've been looking at?
Flags: needinfo?(jyavenard)
Flags: needinfo?(dmajor)
Could be, but I would have expected the crash to be elsewhere then. When the event is run, the monitor is released.
https://hg.mozilla.org/releases/mozilla-release/annotate/43107b7a72e4/xpcom/threads/TaskQueue.cpp#l246

The queue at this stage could now be empty.

If TaskQueue::BeginShutdown/AwaitShutdownIdle is now called on another thread, we could be doing thing that aren't expected: such as having shut-down the taskqueue when event is still running

Event object however is refcounted, and hold a reference to mQueue.

Chris is more familiar than me on this code.
Flags: needinfo?(jyavenard) → needinfo?(cpearce)
I don't think this is a problem in TaskQueue. I looked at the code, and I can't see how shutdown could interleave with the task queue runner to cause a UAF. Also, this crash report https://crash-stats.mozilla.com/report/index/8c55d937-b210-4801-a3d0-bc22e0171229 has a crash on the MediaTimer thread, which will be a regular nsIThread from an nsThreadPool, meaning the crash occurs on non-TaskQueue threads. So it's not obviously TaskQueue specific. I think the problem is more likely to be in MozPromise (I realise bholley said that was unlikely above).
Flags: needinfo?(cpearce)
Assignee: alastor0325 → nobody
Flags: needinfo?(dmajor)
Assigning unowned critical/high security bugs to triage owner. Please find an appropriate assignee for this bug.
Assignee: nobody → giles
Jean-Yves, could you please take over this bug and see if we can get it resolved?
Flags: needinfo?(jyavenard)
Re-assigning to the new triage owner.
Assignee: giles → drno
Flags: needinfo?(drno)
It looks like we still don't really have a good explanation what is causing this.

So our best bet right now appears to wait for bug 1247189, which got re-opened and is currently unassigned.
Flags: needinfo?(drno)
not enough bandwidth sorry...
Flags: needinfo?(jyavenard)
Alastor can I ask you to become the owner of this one again?
Assignee: drno → alwu
Flags: needinfo?(alwu)
Keywords: stalled
sure.
Flags: needinfo?(alwu)
This crash signature didn't appear in recent 6 months, I think we could remove it.

https://crash-stats.mozilla.com/signature/?signature=nsRefPtr%3CT%3E%3A%3AnsRefPtr%3CT%3E%20%7C%20mozilla%3A%3AMozPromise%3CT%3E%3A%3AThenValueBase%3A%3AResolveOrRejectRunnable%3A%3AResolveOrRejectRunnable&date=%3E%3D2018-02-27T17%3A56%3A52.000Z&date=%3C2018-08-28T20%3A56%3A52.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1
Crash Signature: [@ mozilla::MozPromise<T>::ThenValueBase::ResolveOrRejectRunnable::ResolveOrRejectRunnable] [@ nsRefPtr<T>::nsRefPtr<T> | mozilla::MozPromise<T>::ThenValueBase::ResolveOrRejectRunnable::ResolveOrRejectRunnable ] [@ RefPtr<T>::RefPtr<T> | mozilla::MozPro… → [@ mozilla::MozPromise<T>::ThenValueBase::ResolveOrRejectRunnable::ResolveOrRejectRunnable] [@ RefPtr<T>::RefPtr<T> | mozilla::MozPromise<T>::ThenValueBase::ResolveOrRejectRunnable::ResolveOrRejectRunnable ]
The clear use-after-free symptoms seem to be limited to quite old builds.
Keywords: csectype-uaf → csectype-wildptr
In the past month there was a single Fennec 63.0.2 UAF and one in ESR-60.0.3 so not completely gone, but mostly gone.

Neither of the listed crash signatures happen on desktop in 63 or later, and only the one already mentioned for fennec. Does that make this bug "worksforme"?

Should we leave it open to cover possibly related signatures?

[@ mozilla::MozPromise<T>::ThenValueBase::ResolveOrRejectRunnable::~ResolveOrRejectRunnable ]
(2 of them, both _WRITE violations like bp-64c1d523-bb23-4bbf-a4c8-e6fd30181114)

[@ mozilla::MozPromise<T>::ThenValueBase::ResolveOrRejectRunnable::Run ]
(some are _EXEC violations like bp-f3ffd034-3f57-4546-bd7d-0feb10181031)

A vague two-year-old placeholder originally filed on something else and marked "stalled" isn't doing us much good.
Flags: needinfo?(rjesup)
If you go back a little further, you see about a dozen 62.* crashes (they're not common), including clear UAFs on desktop.  I see no real reason to believe this is fixed in 63 given the base crash rate in 62.

most of the crashes (as implied in a comment by drno above in comment 62) involve mozilla::MozPromise<mozilla::TrackInfo::TrackType
(which might imply bug 1247189)

Another (the 63 Fennec crash) involves mozilla::MozPromise<RefPtr<mozilla::AudioData>, called from DecoderDataWithPromise() apparently.

Nils, any chance of progress on bug 1247189?  Or thoughts (jya, etc) on the AudioData UAF?
Flags: needinfo?(rjesup) → needinfo?(drno)

According the discussion in berlin allhands, change this bug to P3 because we couldn't have a solution in current version and we've marked this bug as stall one.

Priority: P1 → P3

By checking the crash report, within the past one year, all crashes happened on Android, so it make sense to change the platform to Android. Thank you.

Severity: critical → S3
Flags: needinfo?(alwu)
OS: Windows → Android

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:alwu, could you consider increasing the severity of this security bug?

For more information, please visit auto_nag documentation.

Flags: needinfo?(alwu)

No crash has been seen in the past year, close this bug. Feel free to open it when it happen again.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(alwu)
Resolution: --- → FIXED

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.

Keywords: stalled
Group: media-core-security → core-security-release
Flags: needinfo?(drno)
Resolution: FIXED → WORKSFORME
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.