| 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
| ||
|
Date: Fri, 4 Jun 2021 10:19:58 +0800 (GMT+08:00)
From: Jiabing Wan <wanjiabing@...o.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Fabio Aiuto <fabioaiuto83@...il.com>,
Ross Schmidt <ross.schm.dev@...il.com>,
Qiang Ma <maqianga@...ontech.com>,
Marco Cesati <marcocesati@...il.com>,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re:Re: [PATCH] staging: rtl8723bs: core: fix some incorrect type warnings
Hi, Greg
I feel so sorry for a uncertain patch. I'll learn closer and fix it.
After learning deeper, I think:
>On Thu, Jun 03, 2021 at 04:24:59PM +0800, Wan Jiabing wrote:
>> Fix some "incorrect type in assignment" in rtw_security.c.
>>
>> The sparse warings:
>> drivers/staging//rtl8723bs/core/rtw_security.c:72:50: warning: incorrect type in assignment
>> drivers/staging//rtl8723bs/core/rtw_security.c:72:50: expected restricted __le32 [usertype]
>> drivers/staging//rtl8723bs/core/rtw_security.c:72:50: got unsigned int
>> drivers/staging//rtl8723bs/core/rtw_security.c:80:50: warning: incorrect type in assignment
>> drivers/staging//rtl8723bs/core/rtw_security.c:80:50: expected restricted __le32 [usertype]
>> drivers/staging//rtl8723bs/core/rtw_security.c:80:50: got unsigned int
>> drivers/staging//rtl8723bs/core/rtw_security.c:124:33: warning: cast to restricted __le32
>> drivers/staging//rtl8723bs/core/rtw_security.c:509:58: warning: incorrect type in assignment
>> drivers/staging//rtl8723bs/core/rtw_security.c:509:58: expected restricted __le32 [usertype]
>> drivers/staging//rtl8723bs/core/rtw_security.c:509:58: got unsigned int
>> drivers/staging//rtl8723bs/core/rtw_security.c:517:58: warning: incorrect type in assignment
>> drivers/staging//rtl8723bs/core/rtw_security.c:517:58: expected restricted __le32 [usertype]
>> drivers/staging//rtl8723bs/core/rtw_security.c:517:58: got unsigned int
>> drivers/staging//rtl8723bs/core/rtw_security.c:621:41: warning: cast to restricted __le32
>>
>> Signed-off-by: Wan Jiabing <wanjiabing@...o.com>
>> ---
>> drivers/staging/rtl8723bs/core/rtw_security.c | 14 +++++++-------
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8723bs/core/rtw_security.c b/drivers/staging/rtl8723bs/core/rtw_security.c
>> index a99f439..4760999 100644
>> --- a/drivers/staging/rtl8723bs/core/rtw_security.c
>> +++ b/drivers/staging/rtl8723bs/core/rtw_security.c
>> @@ -36,7 +36,7 @@ const char *security_type_str(u8 value)
>> void rtw_wep_encrypt(struct adapter *padapter, u8 *pxmitframe)
>> { /* exclude ICV */
>>
>> - unsigned char crc[4];
>> + u8 crc[4];
>
>Why change this?
>
* First reason is that other functions which using "~crc32_le"
are all declaring "u8 crc[4];".
Only this function called "rtw_wep_encrypt" uses "unsigned char crc[4];" to declare crc.
But anothor function called "rtw_wep_decrypt" uses "u8 crc[4];" to declare.
I think it is confusing and the declaration should be unanimous.
* Second reason is that function "crc32_le(~0, payload, length);" returns u32,
so u8[4] is described u32.
* Third reason is that later function called "arc4_crypt" using "const *u8" as parameter.
So I think this change is reasonable.
>>
>> signed int curfragnum, length;
>> u32 keylength;
>> @@ -69,7 +69,7 @@ void rtw_wep_encrypt(struct adapter *padapter, u8 *pxmitframe)
>>
>> length = pattrib->last_txcmdsz-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
>>
>> - *((__le32 *)crc) = ~crc32_le(~0, payload, length);
>> + *((__le32 *)crc) = cpu_to_le32(~crc32_le(~0, payload, length));
>
>Are you sure this does what you think it does?
>
>What exactly is this doing now?
This change might be wrong totally. I feel sorry for this.
arc4_crypt need "const *u8" as parameter, so crc should be type "const *u8".
But it use "__le32", so in my opinion, it should be
*((u32 *)crc) = ~crc32_le(~0, payload, length);
>
>>
>> arc4_setkey(ctx, wepkey, 3 + keylength);
>> arc4_crypt(ctx, payload, payload, length);
>> @@ -77,7 +77,7 @@ void rtw_wep_encrypt(struct adapter *padapter, u8 *pxmitframe)
>>
>> } else {
>> length = pxmitpriv->frag_len-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
>> - *((__le32 *)crc) = ~crc32_le(~0, payload, length);
>> + *((__le32 *)crc) = cpu_to_le32(~crc32_le(~0, payload, length));
>> arc4_setkey(ctx, wepkey, 3 + keylength);
>> arc4_crypt(ctx, payload, payload, length);
>> arc4_crypt(ctx, payload + length, crc, 4);
>> @@ -121,7 +121,7 @@ void rtw_wep_decrypt(struct adapter *padapter, u8 *precvframe)
>> arc4_crypt(ctx, payload, payload, length);
>>
>> /* calculate icv and compare the icv */
>> - *((u32 *)crc) = le32_to_cpu(~crc32_le(~0, payload, length - 4));
>> + *((__le32 *)crc) = cpu_to_le32(~crc32_le(~0, payload, length - 4));
>
>This odd casting feels wrong, why is it correct now?
>
If we want to keep cpu value, we should fix it like this:
*((u32 *)crc) =~crc32_le(~0, payload, length - 4);
If we want to keep le32 value, we should fix it like this:
*((__le32 *)crc) = cpu_to_le32(~crc32_le(~0, payload, length - 4));
These fix are all solve the warnings.
The problem is which one should I choose to meet the author's wishes.
And in this situation, it is hard to choose which one is better, as after this line, the function return directly.
>thanks,
>
>greg k-h
The new fix I choose to meet the author's wishes and fix warnings is following:
(Following content is just asked for suggestions and if it were proper, I would send v2.)
@@ -36,7 +36,7 @@ const char *security_type_str(u8 value)
void rtw_wep_encrypt(struct adapter *padapter, u8 *pxmitframe)
{ /* exclude ICV */
- unsigned char crc[4];
+ u8 crc[4];
signed int curfragnum, length;
u32 keylength;
@@ -69,7 +69,7 @@ void rtw_wep_encrypt(struct adapter *padapter, u8 *pxmitframe)
length = pattrib->last_txcmdsz-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
- *((__le32 *)crc) = ~crc32_le(~0, payload, length);
+ *((u32 *)crc) =~crc32_le(~0, payload, length);
arc4_setkey(ctx, wepkey, 3 + keylength);
arc4_crypt(ctx, payload, payload, length);
@@ -77,7 +77,7 @@ void rtw_wep_encrypt(struct adapter *padapter, u8 *pxmitframe)
} else {
length = pxmitpriv->frag_len-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
- *((__le32 *)crc) = ~crc32_le(~0, payload, length);
+ *((u32 *)crc) = ~crc32_le(~0, payload, length);
arc4_setkey(ctx, wepkey, 3 + keylength);
arc4_crypt(ctx, payload, payload, length);
arc4_crypt(ctx, payload + length, crc, 4);
@@ -121,7 +121,7 @@ void rtw_wep_decrypt(struct adapter *padapter, u8 *precvframe)
arc4_crypt(ctx, payload, payload, length);
/* calculate icv and compare the icv */
- *((u32 *)crc) = le32_to_cpu(~crc32_le(~0, payload, length - 4));
+ *((__le32 *)crc) = cpu_to_le32(~crc32_le(~0, payload, length - 4));
*- or
*-
*- + *((u32 *)crc) = ~crc32_le(~0, payload, length - 4);
*-
*- // !! This code is confusing, because after this line of code, the function return directly. I don't know what is the author's wish.
}
}
@@ -506,7 +506,7 @@ u32 rtw_tkip_encrypt(struct adapter *padapter, u8 *pxmitframe)
if ((curfragnum+1) == pattrib->nr_frags) { /* 4 the last fragment */
length = pattrib->last_txcmdsz-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
- *((__le32 *)crc) = ~crc32_le(~0, payload, length);
+ *((u32 *)crc) = ~crc32_le(~0, payload, length);
arc4_setkey(ctx, rc4key, 16);
arc4_crypt(ctx, payload, payload, length);
@@ -514,7 +514,7 @@ u32 rtw_tkip_encrypt(struct adapter *padapter, u8 *pxmitframe)
} else {
length = pxmitpriv->frag_len-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
- *((__le32 *)crc) = ~crc32_le(~0, payload, length);
+ *((u32 *)crc) = ~crc32_le(~0, payload, length);
arc4_setkey(ctx, rc4key, 16);
arc4_crypt(ctx, payload, payload, length);
@@ -618,7 +618,7 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8 *precvframe)
arc4_setkey(ctx, rc4key, 16);
arc4_crypt(ctx, payload, payload, length);
- *((u32 *)crc) = le32_to_cpu(~crc32_le(~0, payload, length - 4));
+ *((u32 *)crc) = ~crc32_le(~0, payload, length - 4);
* or
*
* + *((__le32 *)crc) = cpu_to_le32(~crc32_le(~0, payload, length - 4));
*
* //!! This fix also confused me. But, IMO, u32 is better to meet the author's wishes.
if (crc[3] != payload[length - 1] || crc[2] != payload[length - 2] ||
crc[1] != payload[length - 3] || crc[0] != payload[length - 4])
--
2.7.4
I think new patch is better, ;).
Please review.
Thanks,
Jiabing
Powered by blists - more mailing lists