Closed Bug 1398268 Opened 5 years ago Closed 5 years ago

[U2F, WebAuthn] Crash when switching between browsers during many verification attempts


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

Other Branch



Tracking Status
firefox57 --- unaffected
firefox59 --- fixed


(Reporter: mwobensmith, Assigned: ttaubert)


(Blocks 1 open bug, )



(1 file)

Attached file log.txt
This test requires Google Chrome.

1. Insert USB hardware key.
2. Open both development build of Fx and latest Google Chrome.
3. Navigate to in both browsers.
4. In Fx, click the "U2F Register" button and perform USB verification.
5. Switch to Chrome and click on the "U2F Register" button 15 or more times, but do NOT perform verification.
6. Switch back to Fx and click on "U2F Register" 1-3 times.


There are other ways to reach this crash, but this set of steps seemed the most easily reproducible. Also, this can be done with either U2F demo or WebAuthN demo, no difference.
Assignee: nobody → jjones
Priority: -- → P2
Summary: Crash when switching between browsers during many verification attempts → [U2F, WebAuthn] Crash when switching between browsers during many verification attempts
From the log:

Thread 64 Crashed:
0   libmozglue.dylib              	0x000000010dd50b19 mozalloc_abort(char const*) + 41
1   libmozglue.dylib              	0x000000010dd50b80 abort + 16
2   XUL                           	0x0000000118e3dab9 __rust_start_panic + 9
3   XUL                           	0x0000000118e3afcd 0x112feb000 + 98893773
4   XUL                           	0x0000000118e3af84 std::panicking::rust_panic_with_hook::h8b9b25777425677b + 436
5   XUL                           	0x0000000118348bbb 0x112feb000 + 87415739
6   XUL                           	0x00000001183386a0 0x112feb000 + 87348896
7   XUL                           	0x0000000118331737 0x112feb000 + 87320375
8     	0x00007fffa93a6d38 __IOHIDDeviceInputReportApplier + 81
9      	0x00007fffa73e39b2 __CFSetApplyFunction_block_invoke + 18
10      	0x00007fffa73cfc8a CFBasicHashApply + 122
11      	0x00007fffa73e3959 CFSetApplyFunction + 185
12     	0x00007fffa93a6c37 __IOHIDDeviceInputReportWithTimeStampCallback + 130
13      	0x0000000129965e14 IOHIDDeviceClass::_hidReportHandlerCallback(void*, int, void*) + 366
14      	0x00007fffa741e213 __CFMachPortPerform + 291
15      	0x00007fffa741e0d9 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41
16      	0x00007fffa741e051 __CFRunLoopDoSource1 + 465
17      	0x00007fffa7415cc5 __CFRunLoopRun + 2389
18      	0x00007fffa7415114 CFRunLoopRunSpecific + 420
Looks like the CF calls our hid report handler callback and we somehow panic in there. The CF APIs really are fun to deal with.
I see three places for the handler to panic:

1) The report argument is null
2) The context argument wasn't actually a living Sender (tx)
3) Maybe you're not supposed to keep Send-ing if the last Send was SendErr?

It appears that #1 is unlikely, because other libraries (hidapi, for example) don't check for null there and the API docs don't say it can be null.

#3 isn't in the documentation, and seems unlikely too.

#2 Seems feasible.
I'd say this is the same as bug 1400969. This probably isn't caused by interaction with Chrome but simply our faulty macOS code.
Not sure what happened, but it seems that I can't reproduce this or even bug 1400969 anymore. Matt, can you please try with the latest Nightly on macOS?
Flags: needinfo?(mwobensmith)
Latest Nightly on Mac is fine now, so I'd call this fixed.
Flags: needinfo?(mwobensmith)
Wait, I spoke too soon. Still reproduces.
Whee, I can reproduce this finally.

> read_new_data_cb 0x1235618c0
> read_new_data_cb 0x1235618c0
> Device::drop() 0x1235618c0
> read_new_data_cb 0x1235618c0

We're of course trying to read data after the device was dropped.
Duplicate of this bug: 1400969
Assignee: jjones → ttaubert
Pushed by
[u2f-hid-rs] Rewrite macOS IOHIDManager communication and state machine r=jcj
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Confirmed fixed as of Nightly 59.0a1, 2017-11-20.
You need to log in before you can comment on or make changes to this bug.