Closed Bug 1403185 Opened 7 years ago Closed 6 years ago

Crash in InvalidArrayIndex_CRASH | nsTArray_Impl<T>::ElementAt | `anonymous namespace''::WindowsGamepadService::HandleRawInput

Categories

(Core :: DOM: Device Interfaces, defect, P3)

Unspecified
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla61
Tracking Status
firefox-esr52 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- fixed

People

(Reporter: mccr8, Assigned: qdot)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-5ab2194b-133c-4b8d-aa74-c65a60170924.
=============================================================

Ting-Yu noticed this crash while triaging Nightly crashes. They are all from a single installation (though I also see a similar crash on 56), but they are all an array bounds access crash so maybe this can be fixed by code inspection.

This is the crash reason for all of these:
  ElementAt(aIndex = 117, aLength = 67)

FWIW, the URLs for these crashes are all NSFW VR sites.
Kyle, just a heads up here in case you want to take a look at these crashes.
Flags: needinfo?(kyle)
Priority: -- → P3
Assignee: nobody → kyle
Flags: needinfo?(kyle)
See Also: → 1404112
Ok, I don't think this has to do with the visited site specifically, as it's probably just using the gamepad API as yet another fingerprinting technique. These sites don't use a WebVR based player yet, though I'm not sure if they're using WebVR detection or not, and we don't have enough info in the crash stack to tell.

The only way we can get this kind of overflow on the button array is if the system is presenting us with an HID device that reports in a way we don't expect, and it doesn't look like we cap values there.

The gamepad API is a good candidate for fuzzing at some point, but for now we should just be able to cap gamepad resource array size as the gamepad info is being built, and report OOB values as invalid or something.
Comment on attachment 8959749 [details]
Bug 1403185 - Fix button value index lookup oob for Windows Gamepads;

https://reviewboard.mozilla.org/r/228598/#review235034

::: dom/gamepad/windows/WindowsGamepad.cpp:866
(Diff revision 1)
>  
>    for (unsigned i = 0; i < usageLength; i++) {
> +    // The button index in usages may be larger than what we detected when
> +    // enumerating gamepads. If so, warn and continue.
> +    if ((usages[i] - 1) >= buttons.Length()) {
> +      NS_WARNING("Trying to set gamepad button with out of bounds index!");

I doubt this warning is going to be useful to anyone, but you're the one maintaining this code now. :)
Attachment #8959749 - Flags: review?(ted) → review+
Pushed by kmachulis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/51394984ff2b
Fix button value index lookup oob for Windows Gamepads; r=ted
Backout by aiakab@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a2fa1060ea47
Backed out changeset 51394984ff2b for build bustages on a CLOSED TREE
Pushed by kmachulis@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/356346485da8
Fix button value index lookup oob for Windows Gamepads; r=ted
Fixed. Forgot to keep length check unsigned.
Flags: needinfo?(kyle)
https://hg.mozilla.org/mozilla-central/rev/356346485da8
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Not sure this is worth backporting given the frequency, but feel free to nominate if you feel strongly otherwise.
I'm pretty sure this has always happened on literally one poor soul's machine with some really odd HID thing hooked up, so not worth uplift unless frequency increases.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: