[PATCH] staging: rtl8723bs: Variable rf_type in function rtw_cfg80211_init_wiphy() could be uninitialized

[PATCH] staging: rtl8723bs: Variable rf_type in function rtw_cfg80211_init_wiphy() could be uninitialized

[Yizhuo]

In function rtw_cfg80211_init_wiphy(), local variable "rf_type" could
be uninitialized if function rtw_hal_get_hwreg() fails to initialize
it. However, this value is used in function rtw_cfg80211_init_ht_capab()
and used to decide the value writing to ht_cap, which is potentially
unsafe.

Signed-off-by: Yizhuo <yzhai003@ucr.edu>
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index 9bc685632651..dd39a581b7ef 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3315,7 +3315,7 @@ static void rtw_cfg80211_init_ht_capab(struct ieee80211_sta_ht_cap *ht_cap, enum
 
 void rtw_cfg80211_init_wiphy(struct adapter *padapter)
 {
-	u8 rf_type;
+	u8 rf_type = RF_MAX_TYPE;
 	struct ieee80211_supported_band *bands;
 	struct wireless_dev *pwdev = padapter->rtw_wdev;
 	struct wiphy *wiphy = pwdev->wiphy;
-- 
2.17.1

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8723bs: Variable rf_type in function rtw_cfg80211_init_wiphy() could be uninitialized

[Dan Carpenter]

On Fri, Sep 27, 2019 at 05:06:51PM -0700, Yizhuo wrote:
> In function rtw_cfg80211_init_wiphy(), local variable "rf_type" could
> be uninitialized if function rtw_hal_get_hwreg() fails to initialize
> it. However, this value is used in function rtw_cfg80211_init_ht_capab()
> and used to decide the value writing to ht_cap, which is potentially
> unsafe.

I feel like this is from a Smatch warning.  Sure, it looks from reading
the code that rtw_hal_get_hwreg() can fail, but actually it cannot.

The longer explanation is that in these rtl drivers if you see a
function with "_hal_" in it that stands for "Hardware Abstraction Layer".
The HAL layer is nonsense.

drivers/staging/rtl8723bs/hal/hal_intf.c
   139  void rtw_hal_get_hwreg(struct adapter *padapter, u8 variable, u8 *val)
   140  {
   141          if (padapter->HalFunc.GetHwRegHandler)
   142                  padapter->HalFunc.GetHwRegHandler(padapter, variable, val);
   143  }

It looks as if reading the hardware register is an optional feature but
obviously that's not possibly true.

We can use Smatch to find out which functions implement the function
pointer:
~/smatch/smatch_data/db/smdb.py functions GetHwRegHandler

drivers/staging/rtl8723bs/hal/sdio_halinit.c | (struct hal_ops)->GetHwRegHandler | GetHwReg8723BS  | 1

So in this driver the ->GetHwRegHandler pointer always points to the
GetHwReg8723BS() function.  Then we can check what the return states
for that function are:

~/smatch/smatch_data/db/smdb.py return_states GetHwReg8723BS

It prints a lot of information but the relevant line is:

drivers/staging/rtl8723bs/hal/sdio_halinit.c | GetHwReg8723BS | 84 |               |     PARAM_SET |   2 |                   *$ |             0-u16max |

Which means that the *val is always set and never uninitialized.  This
is after I have rebuilt my Smatch DB several times.  I rebuild it every
day and it has been a long time since I started from scratch.

So removing the HAL layer would make this code parsable by Smatch and it
would make it more readable for human beings as well.  Another option
would be to just delete the "if (padapter->HalFunc.GetHwRegHandler)"
check which would also silence the false positive.  A third option would
be to add "rtw_hal_get_hwreg 2" to the
~/smatch/smatch_data/kernel.ignore_uninitialized_param file.

regards,
dan carpenter
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel