This bug was filed from the Socorro interface and is report bp-411947f7-dcdf-4353-bfb7-415742161027. ============================================================= Ran into this issue twice while testing Webrtc calls. Nothing special done when running into this, just entered the call and crashed after a few moments. Tested with https://apprtc.appspot.com/ on Windows 7x64 Second crash report: bp-8574ae8b-5f1d-4207-b7f7-2e8de2161027

This is almost certainly the VP9 version of bug 1263384 (which fixed it for VP8, and was fixed in Fx47). Since we stil haven't updated from upstream since then, we need to mirror the patch to VP9. This is a write-past-end-of-allocation bug. Note that VP9 is enabled for webrtc in 51, though not the default codec.

Comment on attachment 8808214 [details] [diff] [review] Add input checks for VP9 Review of attachment 8808214 [details] [diff] [review]: ----------------------------------------------------------------- Same fix, ok. Please add it to input_frame_validation.patch as well so it gets checked on update.

Comment on attachment 8808314 [details] [diff] [review] Add input checks for VP9 Carry forward r+. Updates the update script as well; adds this as a separate patch instead of updating the original patch. [Security approval request comment] How easily could an exploit be constructed based on the patch? Pretty hard, you'd have to figure out how to get it to generate the "wrong" size frame and control the data in that frame. This perhaps could be done with a canvas capture source, but provoking the race condition might be tricky. Then you have a bounds violation with controllable data, so you'd have to turn that into an exploit in some manner. Overall, possible, but not simple. And not very obvious from the patch. Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? No. They do make it clear it's an input-validation issue. This exact same patch for VP8 landed and uplifted to 47, and has already been opened. Which older supported branches are affected by this flaw? 51 and 52 only. If not all supported branches, which bug introduced the flaw? Enabling VP9 by default in 51. Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? Trivial, applies directly. How likely is this patch to cause regressions; how much testing does it need? Virtually no chance of regression.

Not a regression per-se, the bug in VP9 has always been there but was only hittable if you set a pref to enable VP9 in webrtc.

Comment on attachment 8808314 [details] [diff] [review] Add input checks for VP9 Sec-approval+ and I'm approving Aurora too since 50 is unaffected. Let's get this fixed!

jesup: shall we land this on trunk or do you want to land this on inbound ?

I'm good with landing directly on central; inbound would be ok too since I'm sure it'll pick up a merge before uplift