summaryrefslogtreecommitdiffstats
path: root/drivers/scsi/fnic/fnic_res.h
diff options
context:
space:
mode:
authorPhillip Potter <phil@philpotter.co.uk>2022-07-31 01:59:10 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-07-31 10:07:45 +0200
commit87f600af59e8cf6abb04bac15328bcb517e26485 (patch)
tree072f092ca0de3dbb93b34846c58ac8daaab2c2bc /drivers/scsi/fnic/fnic_res.h
parentstaging: r8188eu: remove initializer from ret in rtw_pwr_wakeup (diff)
downloadlinux-87f600af59e8cf6abb04bac15328bcb517e26485.tar.xz
linux-87f600af59e8cf6abb04bac15328bcb517e26485.zip
staging: r8188eu: fix potential uninitialised variable use in rtw_pwrctrl.c
Set ret to 0 (success) before entering first if statement, thereby assuring that even if the device is not associated and further checks pass, we do not then end up returning the uninitialized value of ret. This assignment is deliberately now directly before the if statement, in order to keep it clear what is happening as opposed to having it as an initialization at the start of the function like it was originally. Also add a comment to make it clear this first if block is currently a success path. As a side note, smatch does not trigger warnings for this change, for me at least. Within core/rtw_pwrctrl.c in the rtw_pwr_wakeup function, I previously dropped the initialization of 'ret' (int ret = 0;) in favour of its assignment which happens inside the first if block directly before its corresponding goto. This was the cause of this bug, and was introduced by: commit f3a76018dd55 ("staging: r8188eu: remove initializer from ret in rtw_pwr_wakeup"). Fixes: f3a76018dd55 ("staging: r8188eu: remove initializer from ret in rtw_pwr_wakeup") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20220730235910.1145-1-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/scsi/fnic/fnic_res.h')
0 files changed, 0 insertions, 0 deletions