libusb upstream uses int for register handler. This causes some library
user (like pyusb) to assume that we have int in all implementations and
therefore provides a 4 byte storage only. This causes Segmentation
fault as we will right the pointer.
Details
Details
- Reviewers
adrian aokblast - Group Reviewers
USB - Commits
- rG6bda9f26d2ed: libusb: change callback register handler to int
rGce9ced951a0b: libusb: change callback register handler to int
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
The only conflict is on struct libusb_context in lib/libusb/libusb10.h I believe. Any chance you can rebase and push soon?
| lib/libusb/libusb10_hotplug.c | ||
|---|---|---|
| 376 | Won't this mean an underflow will result in two callbacks being assigned id == 1 ? | |
| lib/libusb/libusb10_hotplug.c | ||
|---|---|---|
| 376 | Yes (this is unchanged from the original commit before rebasing), if the callback is still in use. If the caller registers a callback and then registers & unregisters enough to trigger this wrap. I plan to commit this version shortly to fix the ABI issue as close as possible in time to the so bump, but will add an XXX comment. The signed integer overflow is also UB. | |
Comment Actions
Add XXX comment. Will be in separate commit with
libusb: Add an XXX comment for possible duplicate callback IDs If next_callback_id wraps we could end up with two callbacks with the same ID. I recommitted the original change despite this issue in order to fix the libusb API as soon as possible after SHLIB_MAJOR was bumped in commit 527a82474cb3 (libusb: versioning symbols).
Comment Actions
In practice we probably expect a single-digit callback count, and most likely only one or maybe two, so an O(n) loop over the list to check for a duplicate ID should be OK (we're already doing this regularly anyway).