onlykey-cli segfaults in libusb-1.0.so.0.2.0 at the end of execution

[nkichukov]

Hello team,

I am running onlykey-cli version 1.2.4 here under python 3.8 on GNU/Gentoo Linux amd64 kernel 5.11.7.

Execution of commands work, however, instead of graceful exit I am getting segmentation faults in the end. Seems like they are related to libusb.so:

[Thu Mar 25 17:07:52 2021] onlykey-cli[14300]: segfault at 220 ip 00007fc7df35abfb sp 00007fc7db414d30 error 4 in libusb-1.0.so.0.2.0[7fc7df354000+e000]
[Thu Mar 25 17:07:52 2021] Code: 56 41 55 41 54 55 48 89 fd 53 48 89 f3 48 83 ec 20 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0 48 85 ff 0f 84 55 01 00 00 <8b> 85 20 02 00 00 45 31 e4 85 c0 78 28 48 8b 44 24 18 64 48 2b 04
[Thu Mar 25 17:14:02 2021] onlykey-cli[14904]: segfault at 220 ip 00007ffb79e10bfb sp 00007ffb75ecad30 error 4 in libusb-1.0.so.0.2.0[7ffb79e0a000+e000]
[Thu Mar 25 17:14:02 2021] Code: 56 41 55 41 54 55 48 89 fd 53 48 89 f3 48 83 ec 20 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0 48 85 ff 0f 84 55 01 00 00 <8b> 85 20 02 00 00 45 31 e4 85 c0 78 28 48 8b 44 24 18 64 48 2b 04

versions of additional packages that are used by onlykey-cli:
dev-libs/libusb-1.0.23-r1:1
sys-auth/solo-python-0.0.27:0
dev-libs/hidapi-0.10.1:0
dev-python/hidapi-0.10.1_p20210303:0
dev-python/aenum-2.2.4:0
dev-python/six-1.15.0-r1:0
dev-python/prompt_toolkit-3.0.16:0

I have checked a 'strace -f' execution to try to figure out what goes wrong but nothing obvious in there. Any pointers?

Here is example execution with the segfault failure in the end:

$ onlykey-cli version
OnlyKey CLI v1.2.4
Segmentation fault

[nkichukov]

I've removed solo-python and installed onlykey-solo-python instead [main] branch. No difference.

The GDB output is as follows:

(gdb) run /usr/bin/onlykey-cli fwversion
Starting program: /usr/bin/python3.8 /usr/bin/onlykey-cli fwversion
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after fork from child process 3966]
[New Thread 0x7ffff3527640 (LWP 3968)]
[New Thread 0x7ffff2d26640 (LWP 3969)]
v2.1.0-prodc
[Thread 0x7ffff3527640 (LWP 3968) exited]

Thread 3 "python3.8" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff2d26640 (LWP 3969)]
0x00007ffff6c6bbfb in libusb_get_next_timeout () from /lib64/libusb-1.0.so.0

[onlykey]

We recommend to install OnlyKey CLI via the docs here, $ pip3 install onlykey

https://docs.crp.to/command-line.html#linuxbsd-install-with-dependencies

[nkichukov]

Thanks, but I am running a source based distribution here, this deviates heavily from the way we manage our packages in Gentoo, thus I walk the next mile to make it work as close to the Gentoo philosophy as possible.

Now, if I upgrade libusb to:
dev-libs/libusb-1.0.24-r1:1

The failure has changed a bit, instead of segmentation fault, now I get Abort:

$ onlykey-cli fwversion
v2.1.0-prodc
python3.8: /var/tmp/portage/dev-libs/libusb-1.0.24-r1/work/libusb-1.0.24/libusb/os/threads_posix.h:58: usbi_mutex_destroy: Assertion `pthread_mutex_destroy(mutex) == 0' failed.
Aborted

Which is way more graceful than before. I have also upgraded:
dev-libs/hidapi-9999:0
dev-python/hidapi-9999:0

to the latest version from their git repositories, master branches.

However, if I run the utility without any parameters, ie:

$ onlykey-cli 
OnlyKey CLI v1.2.4
Control-D to exit.


OnlyKey> fwversion

v2.1.0-prodc

OnlyKey>                                                                                                                                                                                                                              

Bye!

There are no issues, as it seems.

What I have observed is, something very similar to the challenge response bug of keepassxc from before, which unbinds one of the required rawhid or just hid devices and then, perhaps because of the Abort or anything else it does not reattach the HID device back to the kernel. So the Onlykey-App thinks that there is no onlykey connected, where in reality it is.

To workaround this, I have re-enabled my additional udev rules to readd the device after some time and then the Onlykey-App picks it up successfully, something similar to:
echo '1-6.2:1.2' > /sys/bus/usb/drivers/usbhid/bind

If this is hard to troubleshoot and you think there is no point in it, I am happy to close as I have a workaround and I have automated the 'settime'.

Thanks

[nkichukov]

Hi Tim,
I have recompiled libusb, python, cython-hidapi, hidapi with debug symbols enabled and was able to collect debug output, including prints from libusb itself, a backtrace and full backtrace. It seems like the 'abort' is generated because the application has left some devices open when exiting the session.

See attached log file.
onlykey-cli-debug-output.txt

Let me know if you need anything else to troubleshoot this further.
Cheers,
-N

[onlykey]

Thanks for the information, I will check the source and see if there are any cases where we open a device but do not close it.

[onlykey]

@nkichukov Can you test this fix? It should now in all cases at exit close USB in case program exits with device open.

$ git clone https://github.com/trustcrypto/python-onlykey -b fix-close-usb
$ cd python-onlykey
$ pip3 install .

[nkichukov]

It works, thank you Tim!

[halt-avmc]

I have very similar symptoms with onlykey-cli v1.2.6
OS: Ubuntu MATE

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.3 LTS
Release:	20.04
Codename:	focal

It works in "interactive mode", i.e. by simply running onlykey-cli in console.

$ onlykey-cli 
OnlyKey CLI v1.2.6
Control-D to exit.


OnlyKey> version

OnlyKey CLI v1.2.6

OnlyKey>                                                                                                                                                                                                                                     

Bye!

But segfaults when executing with arguments. For example

$ onlykey-cli version
OnlyKey CLI v1.2.6
Segmentation fault (core dumped)

Not sure if this is also because of libusb as mentioned earlier in the very beginning topic (because I don't know how to check/verify this)
And unfortunately I can not try workaround from this answer #44 (comment) because git says
fatal: Remote branch fix-close-usb not found in upstream origin
Looks like there is no more such a git-branch

Not to mention app was installed as was said in here https://docs.crp.to/command-line.html#linuxbsd-install-with-dependencies

[onlykey]

@halt-avmc Can you try installing from release here - https://github.com/trustcrypto/python-onlykey/releases/tag/v1.2.8

[halt-avmc]

@halt-avmc Can you try installing from release here - https://github.com/trustcrypto/python-onlykey/releases/tag/v1.2.8

Looks like it works, no more segfaults. Thanks!

I have to admit I am not that python guru, so my "installation" was like simply download src archive, unpack it and replace "onlykey" dir under my local python's site-packages. That are only this files:

onlykey/__init__.py
onlykey/client.py
onlykey/cli.py

I am pretty sure this is not the right way to update. First I tried to pip3 uninstall onlykey and install it again, but it installed the old version onlykey v1.2.6 instead of v.1.2.8
So that is my kind of workaround.

UPD: found more correct way of updating: pip3 install git+https://github.com/trustcrypto/[email protected]