-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix crash when USB device numbers reach 256 #103
Comments
This would be very handy as I've run into this a few times on my Chromebooks. I move my Yubikey between several devices during the day for 2FA/GPG/SSH and after a while that leads to my Chromebook not properly interacting with the Yubikey for SSH to other machines or into Crostini if the Smart Card Connector fails. I've recently disabled Smart Card Connector temporarily due to #122 where it prevents mapping a Yubikey directly into Crostini with VMC but it would be nice to have this bug sorted as well for the times where I just need to SSH to another host and not Crostini. I might be an edge case since I have a Chromebook with tons of RAM that I rarely reboot since more RAM == more open tabs and I have to rely on an extension or two to make closing before a reboot and reopening all of them after a reboot less onerous, but they typically handle per window tab lists and I may have a bunch of tabs "saved" previously by closing them using an extension that I wouldn't want to reopen after a reboot making the session restores more tricky. |
Cherry-pick the following commit from the upstream PC/SC-Lite repository, which fixes a 1.9.1 regression: 7730f6c54d7fb6a910d291e2d48c92d2a5abf688 SetProtocol: Handle IFD_NOT_SUPPORTED from the driver If the driver returns IFD_NOT_SUPPORTED from the function IFDHSetProtocolParameters() it indicates the "command" is not supported. It is different from IFD_PROTOCOL_NOT_SUPPORTED that indicates the "prorocol" is not supported. The problem was with a ACR38U CCID and a memory card. The SetParameters() fails but the card can still be used using the default protocol. The behaviour is identical to what we had before the commit 5d58577093f56dbcfbf754940f885ed8fcdba206. Thanks to Godfrey Chung for the bug report "pcsc-lite 1.9.1: memory card connection failed #103"
Cherry-pick the following commit from the upstream PC/SC-Lite repository, which fixes a 1.9.1 regression: 7730f6c54d7fb6a910d291e2d48c92d2a5abf688 SetProtocol: Handle IFD_NOT_SUPPORTED from the driver If the driver returns IFD_NOT_SUPPORTED from the function IFDHSetProtocolParameters() it indicates the "command" is not supported. It is different from IFD_PROTOCOL_NOT_SUPPORTED that indicates the "prorocol" is not supported. The problem was with a ACR38U CCID and a memory card. The SetParameters() fails but the card can still be used using the default protocol. The behaviour is identical to what we had before the commit 5d58577093f56dbcfbf754940f885ed8fcdba206. Thanks to Godfrey Chung for the bug report "pcsc-lite 1.9.1: memory card connection failed #103"
Chrome is repeatedly crashing on my iPad Pro ,please rectify it regards nawabdera |
NAWABDERA1, please use the standard bug report channel for Chrome issues: https://support.google.com/chrome/answer/95315 |
Currently, the Smart Card Connector crashes once it receives a USB device number from Chrome that exceeds 255.
Such big numbers don't occur usually, since Chrome just uses an internal counter that gets incremented for every new device, but nevertheless these values may be reached if the Chromebook doesn't get rebooted over a long period of time and the user plugs and unplugs devices many times in between.
The crash happens due to hitting the assertion when the value received from Chrome cannot be casted into the 8-bit number used by libusb:
chromeos_smart_card_connector/third_party/libusb/naclport/src/libusb_over_chrome_usb.cc
Line 521 in d48f773
As was written in the comment in the code, one way for fixing this problem is adding code that starts reusing the device numbers once we hit the boundary (e.g., by keeping the track of the most recently used device numbers).
The text was updated successfully, but these errors were encountered: