Skip to content
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: panic when trying to iterate over an interface with zero endpoints #195

Merged

Conversation

alufers
Copy link
Contributor

@alufers alufers commented Mar 5, 2024

Some USB classes (UVC, UAC) provide alternate setting descriptors of interfaces with zero endpoints. Trying to call endpoint_descriptors on them caused a panic, because NULL was passed to slice::from_raw_parts. A branch was introduced to check for that case and create an iterator over an empty slice.

See: https://stackoverflow.com/a/49244874/2948315

Steps to reproduce the bug:

  1. Have a device connected which has an interface (or interface altsetting) with zero endpoints. (for example: 17ef:482f Lenovo Lenovo 500 RGB Camera)
  2. Run RUST_BACKTRACE=1 cargo run --example list_devices on the master branch
  3. Observe panic:
Panic stacktrace
thread 'main' panicked at library/core/src/panicking.rs:155:5:
unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null, and the total size of the slice not to exceed `isize::MAX`
stack backtrace:
   0: rust_begin_unwind
             at /rustc/b381d3ab27f788f990551100c4425bb782d26d76/library/std/src/panicking.rs:647:5
   1: core::panicking::panic_nounwind_fmt::runtime
             at /rustc/b381d3ab27f788f990551100c4425bb782d26d76/library/core/src/panicking.rs:110:18
   2: core::panicking::panic_nounwind_fmt
             at /rustc/b381d3ab27f788f990551100c4425bb782d26d76/library/core/src/panicking.rs:122:9
   3: core::panicking::panic_nounwind
             at /rustc/b381d3ab27f788f990551100c4425bb782d26d76/library/core/src/panicking.rs:155:5
   4: core::slice::raw::from_raw_parts::precondition_check
             at /rustc/b381d3ab27f788f990551100c4425bb782d26d76/library/core/src/intrinsics.rs:2647:21
   5: core::slice::raw::from_raw_parts
             at /rustc/b381d3ab27f788f990551100c4425bb782d26d76/library/core/src/slice/raw.rs:98:9
   6: rusb::interface_descriptor::InterfaceDescriptor::endpoint_descriptors
             at ./src/interface_descriptor.rs:106:27
   7: list_devices::list_devices
             at ./examples/list_devices.rs:70:42
   8: list_devices::main
             at ./examples/list_devices.rs:16:5
   9: core::ops::function::FnOnce::call_once
             at /rustc/b381d3ab27f788f990551100c4425bb782d26d76/library/core/src/ops/function.rs:250:5
             

Details and software versions:

  • rusb master branch (commit 15c2910)
  • libusb 1.0.27
  • rustc 1.78.0-nightly (b381d3ab2 2024-02-12)
  • Linux kernel 6.7.8

Some USB classes (UVC, UAC) provide alternate setting descriptors of interfaces with zero endpoints. Trying to call `endpoint_descriptors` on them caused a panic, because NULL was passed to `slice::from_raw_parts`. A branch was introduced to check for that case and create an iterator over an empty slice.

See: https://stackoverflow.com/a/49244874/2948315
@alufers
Copy link
Contributor Author

alufers commented Mar 5, 2024

I think there seems to be a problem with the macos-latest check, it errors out on some internal libusb assertion. Same error in other PRs in this repo. Probably unrelated to the contents of this PR.

@a1ien
Copy link
Owner

a1ien commented Mar 5, 2024

LGTM. Thank you. Yes, macOS is experiencing issues due to a bug in libusb 1.0.26. I will try to find time to update libusb1-sys to use 1.0.27

@a1ien a1ien merged commit aa11ec9 into a1ien:master Mar 5, 2024
7 of 8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants