linux-kernel - Re: [PATCH RFC 0/3] staging: r8188eu: avoid uninit value bugs

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 22 Aug 2021 11:53:54 +0200
From:   "Fabio M. De Francesco" <fmdefrancesco@...il.com>
To:     Larry.Finger@...inger.net, phil@...lpotter.co.uk,
        gregkh@...uxfoundation.org, straube.linux@...il.com,
        Pavel Skripkin <paskripkin@...il.com>
Cc:     linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
        Pavel Skripkin <paskripkin@...il.com>,
        Michael Straube <straube.linux@...il.com>,
        Martin Kaiser <martin@...ser.cx>
Subject: Re: [PATCH RFC 0/3] staging: r8188eu: avoid uninit value bugs

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