[PATCH 2/2] staging: rtl8192e: Change state information from u16 to u8

[Greg KH]

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