lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2024030406-kilogram-raving-33c5@gregkh>
Date: Mon, 4 Mar 2024 21:04:00 +0000
From: Greg KH <gregkh@...uxfoundation.org>
To: Demi Marie Obenour <demi@...isiblethingslab.com>
Cc: linux-usb@...r.kernel.org,
	Marek Marczykowski-Górecki <marmarek@...isiblethingslab.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: usbip doesn't work with userspace code that accesses USB devices

On Mon, Mar 04, 2024 at 03:01:51PM -0500, Demi Marie Obenour wrote:
> Qubes OS users are reporting that MTP doesn't work with USB passthrough.
> Fastboot (used for flashing a custom OS to an Android device) also
> doesn't work.  Kernel-mode drivers, such as Bluetooth and USB storage,
> seem to usually work as expected.  Since MTP and fastboot are both
> implemented in userspace, it appears that there is some problem with the
> interaction of usbip, our USB proxy (which is based on USBIP), and
> userspace programs that interact with USB devices directly.
> 
> The bug report can be found at [1] and the source code for the USB proxy
> can be found at [2].  The script used on the sending side (the one with
> the physical USB controller) is at [3] and the script used by the
> receiving side (the one the device is attached to) is at [4].  All of
> these links are for the current version as of this email being sent, so
> that anyone looking at this email in the future doesn't get confused.
> 
> Is this a bug in usbip, or is this due to usbip being used incorrectly?

I'm amazed that usbip works with usbfs at all, I didn't think that was a
thing.

If you have a reproducer, or some error messages somewhere, that might
be the easiest way forward.  In reading the bug report, it looks like
the "bridge" you all made can't handle the device disconnecting itself
properly?  But that's just a guess, could be anything.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ