On Friday, August 20, 2021 7:07:28 PM CEST Pavel Skripkin wrote:

Hi, Greg, Larry and Phillip!

I noticed, that new staging driver was added like 3 weeks ago and I decided
to look at the code, because drivers in staging directory are always buggy.

The first thing I noticed is *no one* was checking read operations result, 

but

it can fail and driver may start writing random stack values into registers. 

It

can cause driver misbehavior or device misbehavior.

After the messages I wrote yesterday, I had some minutes to look deeper at the 
code that would be changed by these patches.

I think that it does not look like that the driver could return "random stack 
values into registers" and I think this entire series in unnecessary. 

As far as I understand this driver (though I must admit that I really don't 
know how to write drivers, and I'm not interested in understanding - at the 
moment, at least), all the usb_read*() call usbctrl_vendorreq() and the latter 
*does* proper error checking before returning to the callers the read data. 

Please, look at the code copied from usbctrl_vendorreq() and pasted here (some 
comments are mine):

/* start of code */
static int usbctrl_vendorreq(struct intf_hdl *pintfhdl, u16 value, void 
*pdata, u16 len, u8 requesttype)
{

/* test if everything is OK for transfers and setup the necessary variables */
[...] 

status = usb_control_msg(udev, pipe, REALTEK_USB_VENQT_CMD_REQ,
                                         reqtype, value, 
REALTEK_USB_VENQT_CMD_IDX,
                                         pIo_buf, len, 
RTW_USB_CONTROL_MSG_TIMEOUT);

                if (status == len) {   /*  Success this control transfer. */
                        rtw_reset_continual_urb_error(dvobjpriv);
                        if (requesttype == 0x01)
                                memcpy(pdata, pIo_buf,  len); /* pdata 
receives the read data */
	} else { /*  error cases */

[...]

}
/* end of code */

So, *I cannot ack this RFC*, unless maintainers say I'm missing something.

Larry, Philip, since you have much more knowledge than me about r8188eu (and, 
more in general, on device drivers) may you please say what you think about my 
arguments against this series?

Thanks,

Fabio

To avoid this type of bugs, i've expanded read() API with error parametr,
which will be initialized to error if read fails. It helps callers to
break/return earlier and don't write random values to registers or to rely
on random values.

Why is this pacth series RFC?
  1. I don't have this device and I cannot test these changes.
  2. I don't know how to handle errors in each particular case. For now, 

function

     just returns or returns an error. That's all. I hope, driver 

maintainers will

     help with these bits.
  3. I guess, I handled not all uninit value bugs here. I hope, I fixed
     at least half of them

This series was build-tested and made on top of staging-testing branch


With regards,
Pavel Skripkin