linux-kernel - Re: [PATCH v2] staging: r8188eu: Fix breakage introduced when 5G code was removed

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] [day] [month] [year] [list]

Message-ID: <0d24888e-0132-4a9a-f8cb-4f5a3d4b10c6@lwfinger.net>
Date:   Mon, 8 Nov 2021 09:26:51 -0600
From:   Larry Finger <Larry.Finger@...inger.net>
To:     David Laight <David.Laight@...LAB.COM>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Cc:     "phil@...lpotter.co.uk" <phil@...lpotter.co.uk>,
        "linux-staging@...ts.linux.dev" <linux-staging@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Zameer Manji <zmanji@...il.com>,
        kernel test robot <lkp@...el.com>,
        Stable <stable@...r.kernel.org>
Subject: Re: [PATCH v2] staging: r8188eu: Fix breakage introduced when 5G code
 was removed

On 11/8/21 04:55, David Laight wrote:
> From: Larry Finger
>> Sent: 07 November 2021 17:36
>>
>> In commit 221abd4d478a ("staging: r8188eu: Remove no more necessary definitions
>> and code"), two entries were removed from RTW_ChannelPlanMap[], but not replaced
>> with zeros. The position within this table is important, thus the patch broke
>> systems operating in regulatory domains osted later than entry 0x13 in the table.
>> Unfortunately, the FCC entry comes before that point and most testers did not see
>> this problem.
> ...
>>   drivers/staging/r8188eu/core/rtw_mlme_ext.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/staging/r8188eu/core/rtw_mlme_ext.c b/drivers/staging/r8188eu/core/rtw_mlme_ext.c
>> index 55c3d4a6faeb..5b60e6df5f87 100644
>> --- a/drivers/staging/r8188eu/core/rtw_mlme_ext.c
>> +++ b/drivers/staging/r8188eu/core/rtw_mlme_ext.c
>> @@ -107,6 +107,7 @@ static struct rt_channel_plan_map	RTW_ChannelPlanMap[RT_CHANNEL_DOMAIN_MAX] = {
>>   	{0x01},	/* 0x10, RT_CHANNEL_DOMAIN_JAPAN */
>>   	{0x02},	/* 0x11, RT_CHANNEL_DOMAIN_FCC_NO_DFS */
>>   	{0x01},	/* 0x12, RT_CHANNEL_DOMAIN_JAPAN_NO_DFS */
>> +	{0x00}, /* 0x13 */
>>   	{0x02},	/* 0x14, RT_CHANNEL_DOMAIN_TAIWAN_NO_DFS */
>>   	{0x00},	/* 0x15, RT_CHANNEL_DOMAIN_ETSI_NO_DFS */
>>   	{0x00},	/* 0x16, RT_CHANNEL_DOMAIN_KOREA_NO_DFS */
>> @@ -118,6 +119,7 @@ static struct rt_channel_plan_map	RTW_ChannelPlanMap[RT_CHANNEL_DOMAIN_MAX] = {
>>   	{0x00},	/* 0x1C, */
>>   	{0x00},	/* 0x1D, */
>>   	{0x00},	/* 0x1E, */
>> +	{0x00},	/* 0x1F, */
>>   	/*  0x20 ~ 0x7F , New Define ===== */
>>   	{0x00},	/* 0x20, RT_CHANNEL_DOMAIN_WORLD_NULL */
>>   	{0x01},	/* 0x21, RT_CHANNEL_DOMAIN_ETSI1_NULL */
> 
> Is it worth changing that to use designated array initialisers?
> so:
> 	[0x21] = {0x01} /* RT_CHANNEL_DOMAIN_ETS11_NULL */
> 
> Then the {0x00} entries can be missed out (or just commented as not used).

Yes, we could save a few bytes but risk getting into trouble aligning with some 
other array that I have not located. I think it should be left the way it is.

Larry