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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
