Re: [PATCH] usb: storage: ene_ub6250: set transport_reset to avoid NULL deref

[Nguyen Ngoc Thang]

On Wed, Sep 09, 2026 at 11:59:00PM -0400, Alan Stern wrote:
> Is there any reason to think that usb_stor_Bulk_reset is appropriate for
> the ene_ub6250?

Yes: ene_ub6250 already speaks the Bulk-Only Transport wire format
underneath its own SCSI translation layer. ene_send_scsi_cmd() builds
its command/status packets with the shared struct bulk_cb_wrap /
struct bulk_cs_wrap from include/linux/usb/storage.h (same
'USBC'/'USBS' signatures, US_BULK_CB_WRAP_LEN/US_BULK_CS_WRAP_LEN
framing, and the same "0-length CSW, retry" / "CSW stalled, retry"
recovery logic as usb_stor_Bulk_transport() in transport.c). It only
uses usb_stor_bulk_transfer_buf()/usb_stor_bulk_transfer_sg() over
us->send_bulk_pipe/recv_bulk_pipe -- no control or interrupt transfer
appears anywhere in the transport. So the Bulk-Only Mass Storage Reset
request (0xFF) plus clearing halt on both bulk endpoints, which is
exactly what usb_stor_Bulk_reset() does, matches the actual wire
protocol this device uses -- it isn't a guess.

> Probably a better solution would be either to make usb_stor_probe2()
> check that us->transport_reset isn't NULL, or even better, make
> scsiglue.c:device_reset() fail immediately if us->transport_reset is
> NULL.  Either one of these would work if some other subdriver forgets
> to set transport_reset.

Agreed, that's a real gap independent of this bug -- nothing stops the
next subdriver from making the same mistake. I folded the
usb_stor_probe2() check into v2, next to the existing "transport and
protocol" check, since it's the same class of error and refusing to
probe is the safe default. Kept the ene_ub6250 transport_reset
assignment too, since that's what makes the device actually work
instead of just failing to bind.

v2 to follow.

Nguyen Ngoc Thang