lkml.org 
[lkml]   [2023]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [Intel-wired-lan] [PATCH] ethernet: e1000e: Fix possible uninit bug
From
On 7/10/2023 03:55, Yu Hao wrote:
> I think u16 phy_data = 0 would not hurt us.
> Let me submit a patch which just initializes u16 phy_data = 0.
Good.
>
> Yu Hao
>
> On Wed, Jul 5, 2023 at 8:47 AM Neftin, Sasha <sasha.neftin@intel.com> wrote:
>>
>> On 7/5/2023 03:10, Yu Hao wrote:
>>> The variable phy_data should be initialized in function e1e_rphy.
>>> However, there is not return value check, which means there is a
>>> possible uninit read later for the variable.
>>>
>>> Signed-off-by: Yu Hao <yhao016@ucr.edu>
>>> ---
>>> drivers/net/ethernet/intel/e1000e/netdev.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
>>> b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> index 771a3c909c45..455af5e55cc6 100644
>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> @@ -6910,8 +6910,11 @@ static int __e1000_resume(struct pci_dev *pdev)
>>> /* report the system wakeup cause from S3/S4 */
>>> if (adapter->flags2 & FLAG2_HAS_PHY_WAKEUP) {
>>> u16 phy_data;
>>> + s32 ret_val;
>>
>> why just not initialize u16 phy_data = 0? How did it hurt us? (legacy)
>>
>>>
>>> - e1e_rphy(&adapter->hw, BM_WUS, &phy_data);
>>> + ret_val = e1e_rphy(&adapter->hw, BM_WUS, &phy_data);
>>> + if (ret_val)
>>> + return ret_val;
>>> if (phy_data) {
>>> e_info("PHY Wakeup cause - %s\n",
>>> phy_data & E1000_WUS_EX ? "Unicast Packet" :
>>

\
 
 \ /
  Last update: 2023-07-10 09:56    [W:0.049 / U:0.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site