Could this be  issue 728857 ? There seem to be similar USB DENY messages in the logs.  Issue 728857  appears to have been fixed in 61.

+ejcaruso@ and +vapier@ for any possible insight please. Thank you!

If you're not using generic containers, then  issue 728857  doesn't apply here. device_jail isn't used unless you're inside a container.

Sorry, let me elaborate: The DENY messages are instead generated by permission_broker, so you should check that first. +cc jorgelo@ for that. I assume the USB device is changing its VID:PID and perhaps the new configuration isn't whitelisted in the device policy?

Those DENY messages are common. I don't think they point to any error. On another note, customer (seems to be Netflix) is using wireless receiver/transmitters to connect their Logitech cameras. Inferred from logs: 
2017-10-16T10:55:20.433106+02:00 INFO kernel: [116887.107600] input: Logitech Unifying Device. Wireless PID:404d as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.2/0003:046D:C52B.0003/001D:046D:404D.0005/input/input10
That's not a configuration we support. kotah@ is trying to figure out if they have in fact used such a setup and/or whether they experience this on supported setups as well.

As per customer from the case # : 13476325

They've tested once a 'USB-over-UTP extender', this extender had a transmitter device and receiver device however it is not wireless. And they only tested this extender for a couple of days---and the tests took place years ago, they've never used it in the production environment.
Since then they've use the default Active-USB cable to connect both Speakerphones and the USB cable of the PTZ camera is not extended in the room.

@annaloraine, thanks for update. Can we ask them to gather ChromeOS debug logs from affected device with supported configurations? As far as I checked, both the logs they sent in Oct and Nov seem to suggest they were using the wireless receiver/transmitter.

Hi @Kotah, I have requested this information to the customer. He said that the issue showed up again. See logs and timestamp.

Debug Logs: https://drive.google.com/drive/folders/1QwpKz_dIEWx16TNW5aLYpn7hzL8rp-bM?usp=sharing
Issues started around *10:29 am CET* January 23, 2018 during the meeting

When they use the PTZ camera the screen was not completely black, the images of cameras are not displayed and the image of our own camera at the bottom right is covered with a green overlay. Sound was still working. When the camera image of the PTZ camera fell away, they changed cameras. However, the same behavior happened.

From log - PTZ Pro camera is directly connected, but gets disconnected at 10:29am:

2018-01-23T10:03:37.473541+01:00 INFO kernel: [115092.286353] usb 1-5: new high-speed USB device number 9 using xhci_hcd
2018-01-23T10:03:37.714571+01:00 INFO kernel: [115092.527517] usb 1-5: Product: PTZ Pro Camera
2018-01-23T10:29:20.717913+01:00 INFO kernel: [116636.776961] usb 1-5: USB disconnect, device number 9

Around this time I find GPU hang:

2018-01-23T10:28:14.801419+01:00 INFO kernel: [116570.802655] [drm] stuck on bsd ring
2018-01-23T10:28:14.801446+01:00 INFO kernel: [116570.802673] [drm] GPU crash dump saved to /sys/class/drm/card0/error
2018-01-23T10:28:14.801452+01:00 INFO kernel: [116570.802687] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.

2018-01-23T10:29:11.910478+01:00 WARNING crash_reporter[4832]: Received crash notification for chrome[808] user 1000 (called directly)
2018-01-23T10:29:23.915884+01:00 WARNING crash_reporter[4908]: [user] Received crash notification for chrome[808] sig 6, user 1000 (ignoring call by kernel - chrome crash; waiting for chrome to call us directly

So the issue does seem like  crbug.com/789872 , fixed at M64. ChromeOS M64 is scheduled next week - I would recommend to wait and test M64, or they can preview and test with Beta channel. Feel free to reopen if the issue persists with M64.

@kotah, thanks for the information.