lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250407150210.GM395307@horms.kernel.org>
Date: Mon, 7 Apr 2025 16:02:10 +0100
From: Simon Horman <horms@...nel.org>
To: Wentao Liang <vulab@...as.ac.cn>
Cc: anthony.l.nguyen@...el.com, przemyslaw.kitszel@...el.com,
	andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com,
	intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] e1000e: Add error handling for e1e_rphy_locked()

On Mon, Apr 07, 2025 at 11:41:54AM +0800, Wentao Liang wrote:
> The e1000_suspend_workarounds_ich8lan() calls e1e_rphy_locked to disable
> the SMB release, but does not check its return value. A proper
> implementation can be found in e1000_resume_workarounds_pchlan() from
> /source/drivers/net/ethernet/intel/e1000e/ich8lan.c.
> 
> Add an error check for e1e_rphy_locked(). Log the error message and jump
> to 'release' label if the e1e_rphy_locked() fails.
> 
> Fixes: 2fbe4526e5aa ("e1000e: initial support for i217")
> Cc: stable@...r.kernel.org # v3.5+
> Signed-off-by: Wentao Liang <vulab@...as.ac.cn>
> ---
>  drivers/net/ethernet/intel/e1000e/ich8lan.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> index 2f9655cf5dd9..d16e3aa50809 100644
> --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
> +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> @@ -5497,7 +5497,11 @@ void e1000_suspend_workarounds_ich8lan(struct e1000_hw *hw)
>  			e1e_wphy_locked(hw, I217_SxCTRL, phy_reg);
>  
>  			/* Disable the SMB release on LCD reset. */
> -			e1e_rphy_locked(hw, I217_MEMPWR, &phy_reg);
> +			ret_val = e1e_rphy_locked(hw, I217_MEMPWR, &phy_reg);
> +			if (ret_val) {
> +				e_dbg("Fail to Disable the SMB release on LCD reset.");
> +				goto release;
> +			}
>  			phy_reg &= ~I217_MEMPWR_DISABLE_SMB_RELEASE;
>  			e1e_wphy_locked(hw, I217_MEMPWR, phy_reg);
>  		}

Hi,

The next few lines of this function look like this:

		/* Enable MTA to reset for Intel Rapid Start Technology
		 * Support
		 */
		e1e_rphy_locked(hw, I217_CGFREG, &phy_reg);
		phy_reg |= I217_CGFREG_ENABLE_MTA_RESET;
		e1e_wphy_locked(hw, I217_CGFREG, phy_reg);

And I think that to be consistent with e1000_resume_workarounds_pchlan()
the return value of the above call to e1e_rphy_locked() should also be
checked.

However, I am not at all sure if the current absence of error checking is
intended as part of the logic flow, or if these are oversights.

Have you observed any run-time problems with this code?

I would naively expect that the i217 is or was a widely used device.  And
this code seems to have been around for a well over 10 years in it's
current form. Which makes me thing we should tread carefully when changing
it.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ