Re: rtw88 kernel module error report (UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtw88/phy.c)

Re: rtw88 kernel module error report (UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtw88/phy.c)

[Greg KH]

On Tue, Mar 30, 2021 at 07:26:15AM -0900, Богдан Пилипенко wrote:
> Hi!
> I finded your emails at:
> - https://github.com/lwfinger/rtw88
> - https://wireless.wiki.kernel.org/en/users/drivers/rtl819x
> 
> I have an error in dmesg:
> *dmesg | grep rtw88*
> 
> > [   26.518691] UBSAN: array-index-out-of-bounds in
> > drivers/net/wireless/realtek/rtw88/phy.c:1661:35
> > [   26.518804]  rtw_get_tx_power_params+0xc66/0xd80 [rtw88_core]
> > [   26.518822]  ? check_hw_ready+0x4f/0xa0 [rtw88_core]
> > [   26.518836]  rtw_phy_get_tx_power_index+0x4d/0x1e0 [rtw88_core]
> > [   26.518850]  rtw_phy_set_tx_power_level+0xcc/0x1a0 [rtw88_core]
> > [   26.518864]  rtw_set_channel+0xc1/0x120 [rtw88_core]
> > [   26.518878]  rtw_ops_config+0x87/0xc0 [rtw88_core]
> 
> 
> And many-many cyclic errors like (size 224 & size 512):
> *cat /sys/kernel/debug/kmemleak*

Can you submit a patch for this to resolve the issue as you can
reproduce it easily?

thanks,

greg k-h

Re: rtw88 kernel module error report (UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtw88/phy.c)

[Larry Finger]

On 3/30/21 11:33 AM, Greg KH wrote:
> On Tue, Mar 30, 2021 at 07:26:15AM -0900, Богдан Пилипенко wrote:
>> Hi!
>> I finded your emails at:
>> - https://github.com/lwfinger/rtw88
>> - https://wireless.wiki.kernel.org/en/users/drivers/rtl819x
>>
>> I have an error in dmesg:
>> *dmesg | grep rtw88*
>>
>>> [   26.518691] UBSAN: array-index-out-of-bounds in
>>> drivers/net/wireless/realtek/rtw88/phy.c:1661:35
>>> [   26.518804]  rtw_get_tx_power_params+0xc66/0xd80 [rtw88_core]
>>> [   26.518822]  ? check_hw_ready+0x4f/0xa0 [rtw88_core]
>>> [   26.518836]  rtw_phy_get_tx_power_index+0x4d/0x1e0 [rtw88_core]
>>> [   26.518850]  rtw_phy_set_tx_power_level+0xcc/0x1a0 [rtw88_core]
>>> [   26.518864]  rtw_set_channel+0xc1/0x120 [rtw88_core]
>>> [   26.518878]  rtw_ops_config+0x87/0xc0 [rtw88_core]
>>
>>
>> And many-many cyclic errors like (size 224 & size 512):
>> *cat /sys/kernel/debug/kmemleak*
> 
> Can you submit a patch for this to resolve the issue as you can
> reproduce it easily?

Greg and Богдан,

I had previously reported the memory leak at 
https://marc.info/?l=linux-wireless&m=161677626908838&w=2. Unfortunately, it is 
not obvious how to fix it. When the routine exits, the skb in question belongs 
to mac80211. It is not clear why it does not free it. I also have an Intel 
device that uses iwlmvm. Although the calling sequence to ieee80211_rx_napi() 
looks the same, it does not leak the skb. Unfortunately, none of the mac8800211 
experts have responded to my E-mail.

@Богдан: What kernel version are you using? With kernel HEAD, line 1661 of 
drivers/net/wireless/realtek/rtw88/phy.c is a case statement, which should not 
generate an array overflow.

Larry

Re: Fwd: rtw88 kernel module error report (UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtw88/phy.c)

[Larry Finger]

On 3/30/21 11:23 PM, Богдан Пилипенко wrote:
> I think this should be enough to reproduce the bug:
> 1) enable UBSAN and KMEMLEAK kernel modules. Those modules - are debugger 
> subsystems and are switched off by default. And without those modules errors 
> will be suppressed.
> 2) activate hardened kernel optimizations. Many other kernel 
> configuration options are in config file (attached in first email).

Богдан,

Thanks for the instructions for enabling UBSAN. I have had kmemleak enabled for 
several years.

The array overrun occurs in the reference to bw40_base[group] in the following 
snippit:

         if (rate <= DESC_RATE11M)
                 tx_power = pwr_idx_2g->cck_base[group];
         else
                 tx_power = pwr_idx_2g->bw40_base[group];

In main.h, bw40_base found in struct rtw_2g_txpwr_idx, as u8 bw40_base[5]. In 
other code, channel 14 is assigned as group 5, which is where the problem 
happens. Unfortunately, if I change to bw40_base[6], reading the efuse breaks, 
and I get an rfe of 255. I'm still working on why that happens, but there is 
obviously another bug somewhere.

I wrote to the developer, and he has some ideas regarding the memory leak. I 
will tackle that problem once I figure out why increasing the dimension breaks 
efuse readout.

Larry