Bug 1745874 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Set severity to P3 is because this UAF isn't easy to reproduce, per comment 3, it seems only being able to reproduce on poorly performing environment. I couldn't reproduce this UAF on both central and the build 20211213184707, which is the one used by reporter.

I suspect this issue is caused by [here](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/media/MediaDecoderStateMachine.cpp#3936-3937). The following is the possible situation. 

(1) Shutdown the media sink #1 
When we finish decoding the first frame, we would [suspend the decoder](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/html/HTMLMediaElement.cpp#5444) which causes the [media sink gets shutdown](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/media/MediaDecoderStateMachine.cpp#3914-3915).

(2) Media starts playing, then creating another new media sink #2
In POC file, `audio.play().then(function(){});` will trigger decoder to start playing, and then the play state of decoder will be mirrored to `MDSM`. As the play state is playing, it's possible to trigger [starting media sink](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/media/MediaDecoderStateMachine.cpp#3051-3052) and then create a new media sink.

(3) Resume media sink, which causes incorrectly discard media sink #2 and create another sink #3
We would [resume the decoder](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/html/HTMLMediaElement.cpp#4477) when media element starts playing. Notice that, although this happen before [mDecoder->Play()](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/html/HTMLMediaElement.cpp#4499) (that is the step (2) to change play state), the mirror is done by a direct task, so even if it's called later, it might still be possible to be processed before the resume task (just a regular task).
Set severity to P3 is because this UAF isn't easy to reproduce, per comment 3, it seems only being able to reproduce on poorly performing environment. I couldn't reproduce this UAF on both central and the build 20211213184707, which is the one used by reporter.

I suspect this issue is caused by [here](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/media/MediaDecoderStateMachine.cpp#3936-3937). The following is the possible situation. 

(1) Shutdown the media sink #1 
When we finish decoding the first frame, we would [suspend the decoder](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/html/HTMLMediaElement.cpp#5444) which causes the [media sink gets shutdown](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/media/MediaDecoderStateMachine.cpp#3914-3915).

(2) Media starts playing, then creating another new media sink #2
In POC file, `audio.play().then(function(){});` will trigger decoder to start playing, and then the play state of decoder will be mirrored to `MDSM`. As the play state is playing, it's possible to trigger [starting media sink](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/media/MediaDecoderStateMachine.cpp#3051-3052) and then create a new media sink.

(3) Resume media sink, which causes incorrectly discard media sink #2 and create another sink #3
We would [resume the decoder](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/html/HTMLMediaElement.cpp#4477) when media element starts playing. Notice that, although this happen before [mDecoder->Play()](https://searchfox.org/mozilla-central/rev/125116c312b0a9c438d44e16011b116950caf17e/dom/html/HTMLMediaElement.cpp#4499) (that is the step (2) to change play state), the mirror is done by a direct task, so even if it's called later, it might still be possible to be processed before the resume task (just a regular task).

Therefore, if (2) runs before (3), `ResumeMediaSink()` will just create another new sink, and the old one won't be stopped properly.

Back to Bug 1745874 Comment 8