If you mem::forget() the AsyncTransfer so its drop never runs to cancel the transfer, this buffer may be invalidated or mutably borrowed elsewhere while libusb is still handling a transfer accessing it.

Unfortunately Pin cannot solve this. It's the same problem that Rust APIs for io_uring run into. The transfer needs to own the buffer so that it remains valid in case drop is not run.

Can you even call this with &mut self when the constructor returns it as Pin? If you could obtain a &mut AsyncTransfer without unsafe, then you can also mem::swap it, and your use of Pin wouldn't be doing any good in protecting its self-reference.

Yeah, you're right. I put it as mut because I wasnt sure if it would be safe to have it as a shared reference. Can I just change it to &? Would I need to make it !Sync?

Or perhaps it should be submit(self: &mut Pin<Box<Self>>) ?

I think its fixed now, lmk

&self may actually be safe given the locking inside libusb_submit_transfer, but I'd have to look more closely.

If the user-supplied callback panics, it's undefined behavior for it to propagate into C, so this needs a catch_unwind.

libusb_cancel_transfer in the drop implementation requests cancellation asynchronously, but after drop returns, the AsyncTransfer memory may be invalidated before this callback is guaranteed to run (or complete, if already running on another thread). The callback may even still be called with a transfer completion after cancellation if it was in the middle of completing at the time of cancellation. Therefore this reference is not guaranteed to be valid.

The callback may even still be called with a transfer completion after cancellation if it was in the middle of completing at the time of cancellation.
Are you saying this ordering is possible:

1. Submit transfer
2. Drop
3. Callback informs of cancellation
4. Callback informs of transfer completion

I wouldn't expect 4 to ever come before 3 - are you sure that is possible? If not possible, perhaps I could actually intentionally leak the struct with Box::leak, and then get the box back inside the cancellation callback and properly drop the components?

The callback should only get called once for a single transfer (until resubmitted), so you won't get both 3 and 4. What I'm not sure about is if you can get a LIBUSB_TRANSFER_COMPLETED callback after calling libusb_transfer_cancel if the transfer has already completed but the event loop has not called the callback yet, or whether this would still be LIBUSB_TRANSFER_CANCELLED but have nonzero actual_length.

I think deferring the drop to the callback could work, though I'd probably use ManuallyDrop over Box::leak to make it explicit.

This is the only call to libusb_free_transfer. If the transfer has already completed on drop, the callback is never called with this status and the libusb_transfer is leaked.

One other safety consideration is that the transfer is no longer considered busy by libusb at the time of the callback, and the AsyncTransfer might be owned by another thread that could resubmit it during the execution of this callback or the user closure. That would illegally alias and mutate the transfer and buffer references here.