rebind_store calls do_rebind which dereferences udev without
checking if it is NULL. If busid is registered using match_busid
but the device is not present in the first place, it triggers a
null pointer dereference when we attempt to rebind the device.
Fix this by checking explicitly for udev first and returning
-ENODEV if udev is NULL.

Reported-by: syzbot+af76b01c9a0f0ab60fb0@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=af76b01c9a0f0ab60fb0
Fixes: 4bfb141bc013 ("usbip: usbip_host: fix to hold parent lock for device_attach() calls")
Cc: stable@vger.kernel.org
Signed-off-by: Jeffin Philip <jeffinphilip14@gmail.com>
---
 drivers/usb/usbip/stub_main.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
index 79110a69d697..dfaedecedb81 100644
--- a/drivers/usb/usbip/stub_main.c
+++ b/drivers/usb/usbip/stub_main.c
@@ -256,6 +256,11 @@ static ssize_t rebind_store(struct device_driver *dev, const char *buf,
 	if (!bid)
 		return -ENODEV;
 
+	if (!bid->udev) {
+		put_busid_priv(bid);
+		return -ENODEV;
+	}
+
 	/* mark the device for deletion so probe ignores it during rescan */
 	bid->status = STUB_BUSID_OTHER;
 	/* release the busid lock */
-- 
2.55.0

On 06 Aug 2026, 05:17 UTC, Jeffin Philip wrote:

>rebind_store calls do_rebind which dereferences udev without
>checking if it is NULL. If busid is registered using match_busid
>but the device is not present in the first place, it triggers a
>null pointer dereference when we attempt to rebind the device.
>Fix this by checking explicitly for udev first and returning
>-ENODEV if udev is NULL.

Reproduce the issue using:
echo "add 1-1" > /sys/bus/usb/drivers/usbip-host/match_busid
echo "1-1" > /sys/bus/usb/drivers/usbip-host/rebind

Thanks,
Jeffin

On Thu, Aug 06, 2026 at 10:47:26AM +0530, Jeffin Philip wrote:
> rebind_store calls do_rebind which dereferences udev without
> checking if it is NULL. If busid is registered using match_busid
> but the device is not present in the first place, it triggers a
> null pointer dereference when we attempt to rebind the device.
> Fix this by checking explicitly for udev first and returning
> -ENODEV if udev is NULL.
> 
> Reported-by: syzbot+af76b01c9a0f0ab60fb0@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=af76b01c9a0f0ab60fb0
> Fixes: 4bfb141bc013 ("usbip: usbip_host: fix to hold parent lock for device_attach() calls")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jeffin Philip <jeffinphilip14@gmail.com>
> ---
>  drivers/usb/usbip/stub_main.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
> index 79110a69d697..dfaedecedb81 100644
> --- a/drivers/usb/usbip/stub_main.c
> +++ b/drivers/usb/usbip/stub_main.c
> @@ -256,6 +256,11 @@ static ssize_t rebind_store(struct device_driver *dev, const char *buf,
>  	if (!bid)
>  		return -ENODEV;
>  
> +	if (!bid->udev) {
> +		put_busid_priv(bid);
> +		return -ENODEV;
> +	}

What prevents bid->udev from becoming NULL right after you checked this?

How was this tested?

thanks,

greg k-h

On Thu, Aug 06 2026, Greg KH wrote:
>What prevents bid->udev from becoming NULL right after you checked this?
We could use usb_get_dev() and hold a reference to udev when the busid_lock
is being held and then release it after do_rebind, or would that be incorrect?

>How was this tested?
The method to reproduce it is in the same thread.

Thanks,
Jeffin.

On Thu, Aug 06, 2026 at 11:06:51AM +0530, Jeffin Philip wrote:
> On Thu, Aug 06 2026, Greg KH wrote:
> >What prevents bid->udev from becoming NULL right after you checked this?
> We could use usb_get_dev() and hold a reference to udev when the busid_lock
> is being held and then release it after do_rebind, or would that be incorrect?

I do not know, try it and see!

> >How was this tested?
> The method to reproduce it is in the same thread.

How is this just now an issue?  What changed to cause it to suddenly
start happening, or has this codepath never been tested?

thanks,

greg k-h

On Thu, Aug 06, 2026 at 07:42:27 +0200, Greg KH wrote:
>On Thu, Aug 06, 2026 at 11:06:51AM +0530, Jeffin Philip wrote:
>> On Thu, Aug 06 2026, Greg KH wrote:
>> >What prevents bid->udev from becoming NULL right after you checked this?
>> We could use usb_get_dev() and hold a reference to udev when the busid_lock
>> is being held and then release it after do_rebind, or would that be incorrect?
>
>I do not know, try it and see!

I tested usb_get_dev() and usb_put_dev() on the rebind path and it compiled
without errors. No undesired behavior during rebind either.

>> >How was this tested?
>> The method to reproduce it is in the same thread.
>
>How is this just now an issue?  What changed to cause it to suddenly
>start happening, or has this codepath never been tested?

Nothing has changed AFAIK. The driver itself depended on sequential
order of operations and in doing so, failed to secure itself against
non-sequential order of operations.

I will send patch v2 soon addressing these issues.

Thanks,
Jeffin.