linux-kernel - Re: [PATCH 2/2] staging: rtl8192e: Change state information from u16 to u8

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]

Message-ID: <YDPNKTHZqaS37XPe@kroah.com>
Date:   Mon, 22 Feb 2021 16:26:33 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Atul Gopinathan <atulgopinathan@...il.com>
Cc:     tiwai@...e.de, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org, gustavo@...eddedor.com
Subject: Re: [PATCH 2/2] staging: rtl8192e: Change state information from u16
 to u8

On Sun, Feb 21, 2021 at 10:27:21PM +0530, Atul Gopinathan wrote:
> On Sun, Feb 21, 2021 at 02:08:26PM +0100, Greg KH wrote:
> > On Sat, Feb 20, 2021 at 11:51:55PM +0530, Atul Gopinathan wrote:
> > > The "CcxRmState" field in struct "rtllib_network" is defined
> > > as a u16 array of size 2 (so, 4 bytes in total).
> > > 
> > > But the operations performed on this array throughout the code
> > > base (in rtl8192e/) are all in byte size 2 indicating that this
> > > array's type was defined wrongly.
> > > 
> > > There are two situation were u16 type of this field could yield
> > > incorrect behaviour:
> > > 
> > > 1. In rtllib_rx.c:1970:
> > > memcpy(network->CcxRmState, &info_element->data[4], 2);
> > > 
> > > Here last 2 bytes (index 4 and 5) from the info_element->data[]
> > > array are meant to be copied into CcxRmState[].
> > > Note that "data" array here is an array of type u8.
> > > 
> > > 2. In function "update_network()" in staging/rtl8192e/rtllib_rx.c:
> > > memcpy(dst->CcxRmState, src->CcxRmState, 2);
> > > 
> > > Here again, only 2 bytes are copied from the source state to
> > > destination state.
> > > 
> > > There are no instances of "CcxRmState" requiring u16 data type.
> > > Here is the output of "grep -IRn 'CcxRmState'" on the rtl8192e/
> > > directory for reviewing:
> > > 
> > > rtllib_rx.c:1970:			memcpy(network->CcxRmState, &info_element->data[4], 2);
> > > rtllib_rx.c:1971:			if (network->CcxRmState[0] != 0)
> > > rtllib_rx.c:1975:			network->MBssidMask = network->CcxRmState[1] & 0x07;
> > > rtllib_rx.c:2520:	memcpy(dst->CcxRmState, src->CcxRmState, 2);
> > > rtllib.h:1108:	u8	CcxRmState[2];
> > 
> > You just changed the logic in line 1975 in that file, right?  Are you
> > _SURE_ that is ok?  Do you have a device to test this on?
> 
> I'm sorry, I didn't quite get you. By line 1975 in rtllib_rx.c, did you mean
> the following line?:
> 
> network->MBssidMask = network->CcxRmState[1] & 0x07;

Yes.

> network->CcxRmState is being fed with 2 bytes of u8 data, in line 1970 (as
> seen above). I believe my patch doesn't change the logic of an "&" operation
> being performed on it with 0x07, right?

It changes the location of the [1] operation to point to a different
place in memory from what I can tell, as you changed the type of that
array.

thanks,

greg k-h