linux-kernel - Re: [PATCH RFC v2 5/6] staging: r8188eu: add error handling of rtw

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:   Tue, 24 Aug 2021 11:46:03 +0200
From:   "Fabio M. De Francesco" <fmdefrancesco@...il.com>
To:     Phillip Potter <phil@...lpotter.co.uk>,
        Pavel Skripkin <paskripkin@...il.com>
Cc:     Larry Finger <Larry.Finger@...inger.net>,
        Greg KH <gregkh@...uxfoundation.org>,
        Michael Straube <straube.linux@...il.com>,
        "open list:STAGING SUBSYSTEM" <linux-staging@...ts.linux.dev>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC v2 5/6] staging: r8188eu: add error handling of rtw_read32

On Tuesday, August 24, 2021 10:53:35 AM CEST Pavel Skripkin wrote:
> On 8/24/21 11:47 AM, Pavel Skripkin wrote:
> > On 8/24/21 11:38 AM, Fabio M. De Francesco wrote:
> > 
> > Hi, Fabio!
> > 
> > previous usb_read16() realization, which is 100% right:
> > 
> > 
> > static u16 usb_read16(struct intf_hdl *pintfhdl, u32 addr)
> > {
> > 	u8 requesttype;
> > 	u16 wvalue;
> > 	u16 len;
> > 	__le32 data;

Ah, it was in plain sight! How didn't I notice it? :(

> > 
> > 	requesttype = 0x01;/* read_in */
> > 	wvalue = (u16)(addr & 0x0000ffff);
> > 	len = 2;
> > 	usbctrl_vendorreq(pintfhdl, wvalue, &data, len, requesttype);
> > 
> > 	return (u16)(le32_to_cpu(data) & 0xffff);
> > }
> > 
> > 
> > Bases on this code, I think, it's oblivious, that data comes in
> > little-endian. That's why I leaved temp variable for casting le32 to
> > cpu's endianess.

Yes you did well (if we trust the old code :)), anyway I guess it
was correct because I've just seen that data is __le32 also in other Realtek
drivers.

> > 
> > I could just read into u{16,32} * and then make smth like
> > 
> > *data = le32_to_cpu(*data)
> > 
> > but static analysis tools will complain about wrong data type passed to
> >    le32_to_cpu()

Obviously the (not broken) tools should catch that and complain.

> > + Phillip tested fixed v2 version and it worked well for him. I guess,
> > Phillip was able to spot weird driver behavior, if this cast is wrong.
> > 
> 		^^^^^&
> 
> I am wrong with this statement, I guess. Most likely, Phillip is testing 
> on smth like x64 and this arch is le, so...
> 
> With regards,
> Pavel Skripkin
> 
Thanks,

Fabio