Re: [PATCH] staging: rtl8712: fix uninit-value "data" and "mac"

[Dan Carpenter]

On Fri, Apr 15, 2022 at 05:47:05PM +0800, Wang Cheng wrote:
> > > diff --git a/drivers/staging/rtl8712/usb_ops_linux.c b/drivers/staging/rtl8712/usb_ops_linux.c
> > > index f984a5ab2c6f..e321ca4453ca 100644
> > > --- a/drivers/staging/rtl8712/usb_ops_linux.c
> > > +++ b/drivers/staging/rtl8712/usb_ops_linux.c
> > > @@ -495,12 +495,14 @@ int r8712_usbctrl_vendorreq(struct intf_priv *pintfpriv, u8 request, u16 value,
> > >  	}
> > >  	status = usb_control_msg(udev, pipe, request, reqtype, value, index,
> > >  				 pIo_buf, len, 500);
> > > -	if (status > 0) {  /* Success this control transfer. */
> > > -		if (requesttype == 0x01) {
> > > -			/* For Control read transfer, we have to copy the read
> > > -			 * data from pIo_buf to pdata.
> > > -			 */
> > > -			memcpy(pdata, pIo_buf,  status);
> > > +	/* For Control read transfer, copy the read data from pIo_buf to pdata
> > > +	 * when control transfer success; otherwise init *pdata with 0.
> > > +	 */
> > > +	if (requesttype == 0x01) {
> > > +		if (status > 0)
> > > +			memcpy(pdata, pIo_buf, status);
> > > +		else
> > > +			*(u32 *)pdata = 0;
> > >  		}
> > 
> > This isn't really correct.  In many cases status is "len" is less than 4.
> > I'm slightly surprised that nothing complains about that as an
> > uninitialized access.  But then another problem is that "status" can be
> > less than "len".
> 
> Sorry, I should explain it clearly. If I did right, watching "status"
> with gdb while running syzkaller reproducer, "status" returns from
> usb_control_msg() is -71. In which case, *pdata won't be touched in
> r8712_usbctrl_vendorreq(). As a result, "data" in
> usb_read8()/usb_read16()/usb_read32() will be returned without
> initialization. I think that is why kmsan reports:
> Local variable data created at:
>  usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33
>  r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29
> 
> > 
> > A better fix instead of setting pdata to zero would be to add error
> > checking in the callers and then change this code to use
> > usb_control_msg_send/recv().  Probably just initialize "data" in the
> > callers as well.
> 
> I tried something similar which also works fine, but I think this patch
> does't fix it at root.
> https://syzkaller.appspot.com/text?tag=Patch&x=15be2970f00000

Oh...  I meant initialize data on the success path as well.

	__le32 data = 0;

You're saying that kasan generates a warning for your updated patch?
Earlier I mentioned "I'm slightly surprised that nothing complains about
that as an uninitialized access." so I guess maybe it does complain?
Good.

regards,
dan carpenter