Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: Larry Finger <larry.finger@gmail.com>
Subject: Re: Fwd: rtw88 kernel module error report (UBSAN:
 array-index-out-of-bounds in drivers/net/wireless/realtek/rtw88/phy.c)
To:     =?UTF-8?B?0JHQvtCz0LTQsNC9INCf0LjQu9C40L/QtdC90LrQvg==?= 
        <bogdan.pylypenko107@gmail.com>, linux-wireless@vger.kernel.org
References: <CALw23pC5kFE23g8M97KJY5vK8-eP1dWPj3jze=j4Mi=NjHks0w@mail.gmail.com>
 <YGNS7WKlBmLrM9/d@kroah.com>
 <CALw23pDE4dqjYapETUsxSJ5bhFHraRm3P4nsMq7o+_30rVXKkQ@mail.gmail.com>
 <CALw23pDmLVSTEN4i7tef9a32jDhBVJ5MuAfDP5L5VL0rxi=vow@mail.gmail.com>
From:   Larry Finger <Larry.Finger@lwfinger.net>
Message-ID: <1d2da979-78b0-6b94-8e0e-fb0b3c75bd5a@lwfinger.net>
Date:   Wed, 31 Mar 2021 15:16:14 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <CALw23pDmLVSTEN4i7tef9a32jDhBVJ5MuAfDP5L5VL0rxi=vow@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

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