Thanks for the report. Unfortunately there's not a lot here for us to go off and I think it could be a driver issue rather than Chrome due to the fact that windows detects the problem. But +engedy from WebAuth. Also +reillyg  and +scheib who may know more.

Could you please check chrome://crashes to see if a crash report appears there as a result?

No Crash Report is generated, it's completely repeatable, even after a reboot, have disabled all Non-Google Chrome Extensions as well. Completely open to ideas about how to provide better documentation? 

Windows Crash Dialog

Deleted: crash dialog.jpg 31.3 KB

	crash dialog.jpg 31.3 KB View Download

If Chrome failed to catch and report the crash properly there may still be a dump file in C:\Users\<Username>\AppData\Local\CrashDumps.

Because Chrome and not the whole system crashes this is likely not a driver issue but could be a problem caused by another piece of software installed on your system. Hopefully the crash dump, if you can find one, will shed light on what is causing the issue.

Great Call - got a bunch of them from this issue. 

Have like 5 more, but I expect this is more than enough! 

Deleted: chrome.exe.67912.dmp 4.0 MB

chrome.exe.67912.dmp 4.0 MB Download

Deleted: chrome.exe.60964.dmp 4.2 MB

chrome.exe.60964.dmp 4.2 MB Download

Deleted: chrome.exe.63172.dmp 3.5 MB

chrome.exe.63172.dmp 3.5 MB Download

Deleted: chrome.exe.66828.dmp 3.9 MB

chrome.exe.66828.dmp 3.9 MB Download

Unhandled exception at 0x000007FECF360A61 (chrome.dll) in chrome.exe.60964.dmp: 0xC0000409: The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application (parameters: 0x0000000000000002).

>	chrome.dll!init_device(libusb_device * dev, libusb_device * parent_dev, unsigned char port_number, char * device_id, unsigned long devinst) Line 1191	C
 	chrome.dll!windows_get_device_list(libusb_context * ctx, discovered_devs * * _discdevs) Line 1633	C
 	chrome.dll!libusb_get_device_list(libusb_context * ctx, libusb_device * * * list) Line 683	C
 	chrome.dll!device::`anonymous namespace'::GetDeviceListOnBlockingThread(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & new_device_path, scoped_refptr<device::UsbContext> usb_context, scoped_refptr<base::SequencedTaskRunner> task_runner, const base::Callback<void __cdecl(libusb_device * *,unsigned __int64),1,1> & callback) Line 120	C++
 	chrome.dll!base::internal::Invoker<base::internal::BindState<void (__cdecl*)(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const & __ptr64,scoped_refptr<device::UsbContext>,scoped_refptr<base::SequencedTaskRunner>,base::Callback<void __cdecl(libusb_device * __ptr64 * __ptr64,unsigned __int64),1,1> const & __ptr64),std::basic_string<char,std::char_traits<char>,std::allocator<char> >,scoped_refptr<device::UsbContext>,scoped_refptr<base::SingleThreadTaskRunner>,base::Callback<void __cdecl(libusb_device * __ptr64 * __ptr64,unsigned __int64),1,1> >,void __cdecl(void)>::Run(base::internal::BindStateBase * base) Line 343	C++
 	chrome.dll!base::debug::TaskAnnotator::RunTask(const char * queue_function, base::PendingTask * pending_task) Line 59	C++
 	chrome.dll!base::MessageLoop::RunTask(base::PendingTask * pending_task) Line 424	C++
 	chrome.dll!base::MessageLoop::DoWork() Line 527	C++
 	chrome.dll!base::MessagePumpForUI::DoRunLoop() Line 174	C++
 	chrome.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate) Line 58	C++
 	chrome.dll!base::RunLoop::Run() Line 38	C++
 	chrome.dll!content::BrowserThreadImpl::FileThreadRun(base::RunLoop * run_loop) Line 253	C++
 	chrome.dll!content::BrowserThreadImpl::Run(base::RunLoop * run_loop) Line 305	C++
 	chrome.dll!base::Thread::ThreadMain() Line 336	C++
 	chrome.dll!base::`anonymous namespace'::ThreadFunc(void * params) Line 91	C++
 	[External Code]	

The crash appears to be caused by the enumeration of a Microsoft LifeCam Cinema. Since this is not a built-in device can you try disconnecting it from the system to confirm that it is triggering the crash?

Wow - That's Random - Confirmed, Camera Unplugged and Keys successfully added. 

Thanks ! Do you guys share this with MS or just code around their crap?

There likely is a real bug in Chrome however the exception indicates the the issue was caught by the stack overflow protections which only detect the memory corruption after the fact which will make diagnosis difficult.

Adding vapier@ because it is interesting that Breakpad didn't catch this exception and upload a normal crash report.

Removing Blink>WebAuthentication because this isn't an issue with the new Blink WebAuthn code.

It would be nice to be able to reproduce this crash locally. Can you provide the exact model number of the camera involved?

https://www.amazon.com/Microsoft-H5D-00013-LifeCam-Cinema/dp/B009CPC6QA

Model 1393, I think it's that one on Amazon, but not 100% Sure. they look identical. 

Also Attached details of the driver versions of the camera and the LifeCam Software. 

Deleted: camera details 1.jpg 179 KB

	camera details 1.jpg 179 KB View Download

Deleted: camera details 2.jpg 41.9 KB

	camera details 2.jpg 41.9 KB View Download

hasn't Windows migrated to Crashpad now ?

I can't keep the two of them straight. Whatever system catches crashes on Windows should have caught this one.

Windows doesn't allow us to catch everything. We can look to see if this is one that we should have caught or if it's one that it keeps for itself without giving us a chance.

reillyg: Thanks for digging into this! Tentatively assigning to you to track the potential security bug. It may be that we don't have enough information to do anything atm.

I would suggest that we file a separate bug for the crash reporting improvements which probably does not need to be tracked as a security issue.

reillyg: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue is blocked on getting ahold of the device which triggers this problem or successfully examining the code to determine the cause of the stack corruption. Given that the cause of this issue system configuration and not user actions or web content (though it is triggered by both) we may want to lower the severity.

However, without accurate counting of crashes in the crash dashboard (because crash reports are not being uploaded for this issue) it is difficult to determine the number of users affected by this issue.

greglaws@gmail.com, thanks for report. Do you have any timing information for when you first noticed this. Did it appear only after adding one of the devices (key or camera) to the computer?

I now have a LifeCam Cinema on my desk (VID/PID 045e 075d). I installed it on a Win10 PC and added a YubiKey -- actually technically a "Gnubby U2F" with VID/PID 1050 0200. I didn't install anything from the CD that came with the webcam and Microsoft's support page says no additional drivers are required on Win8 or later:

https://www.microsoft.com/accessories/en-us/products/webcams/lifecam-cinema/h5d-00013#techspecs-connect

With the LifeCam installed and connected, I logged into a Gmail account and successfully added the gnubby as a security key. No crashes or errors.

The installed drivers in Driver File Details are different from the screenshot greglaws@ posted above. I only see ksthunk.sys and usbvideo.sys, none of the LifeCam-specific drivers.

I downloaded the LifeCam 3.0 software here:

https://www.techspot.com/drivers/driver/file/information/12826/

It installed successfully, but threw up a warning: "This software is not supported on this operating system version and some features might not work. Do you want to continue running Setup?"

Post installation, I see the same list of drivers as in greglaws@'s screenshot. After the installer finished it opened the LifeCam software, which seemed to be working correctly. I could see the live video feed, at least.

I deregistered the security key from the Gmail account and rebooted to make sure the drivers were installed. I then tried the repro steps again but the key registration completed successfully (no crashes or errors).

I think it's likely we'll need a Windows 7 PC to repro this bug.

Given the differences between the USB stacks on Windows 7 and Windows 10 it will be useful for our team to maintain a Windows 7 PC for this purpose.

reillyg, think a VM is worth trying before dedicating hardware?

Got a Win7 VM set up but still was unable to repro. I installed the LifeCam 3.6 software and successfully added a Gnubby U2F (VID/PID 1050 0200) to a Google account using the latest Chrome Stable (60.0.3112.101).

The camera also reported it had a firmware update available. I tried again after installing CinemaFW1033.exe but it still did not repro.

Still no repro with a Windows 7 laptop.

I installed the LifeCam software from the included CD on a Sony Vaio VPCSA31FX running Windows 7 Home Premium SP1 64-bit and updated Chrome to the latest stable version (60.0.3112.113). I was able to successfully add a security key to a Google account.

I did see one crash while investigating this, but from the crash log it appears to be related to Bluetooth. The crash occurred while refreshing chrome://device-log.

https://crash.corp.google.com/browse?q=ReportID%3D%279c8afecddc03ff73

The Vaio has both USB 2.0 and 3.0 ports. I tried the repro steps with the webcam plugged into each of the ports on the system. I also tried connecting the device to a (USB 2.0) hub, and connected the hub to each of the ports. No luck!

We've currently exhausted all ideas we have to reproduce this.  If we can't reproduce it we'll have to shelve it as not actionable.  In that case we would still hope that an eventual rewrite off of using libusb will address this issue, but that engineering work is on hold.

mattreynolds: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Resolving this as WontFix since we can't reproduce this issue locally.

The NextAction date has arrived: 2017-09-13

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot