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: <Zmhby7DtfLGVj+8V@alpha.franken.de>
Date: Tue, 11 Jun 2024 16:14:35 +0200
From: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: Florian Fainelli <florian.fainelli@...ecomint.eu>,
	Ralf Baechle <ralf@...ux-mips.org>, Phil Sutter <n0-1@...ewrt.org>,
	linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] MIPS: Routerboard 532: Fix vendor retry check code

On Wed, May 08, 2024 at 03:07:00PM +0300, Ilpo Järvinen wrote:
> read_config_dword() contains strange condition checking ret for a
> number of values. The ret variable, however, is always zero because
> config_access() never returns anything else. Thus, the retry is always
> taken until number of tries is exceeded.
> 
> The code looks like it wants to check *val instead of ret to see if the
> read gave an error response.
> 
> Fixes: 73b4390fb234 ("[MIPS] Routerboard 532: Support for base system")
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
> --
> 
> IMPORTANT NOTE TO MAINTAINER:
> 
> This change has potential of breaking something and I don't have HW to
> test this with. I only came across it while going through all PCIBIOS_*
> call chains. Clearly the current code non-sensical so something is not
> right but whether this is the right way to solve the problem, I'm not
> entirely sure because it will make small change into the behavior.

I have rework of this code sitting in one of my development branches
and I didn't spot the bug in the old code, but the new code does
what your fix is doing. So I'm pretty sure this change is correct.

> ---
>  arch/mips/pci/ops-rc32434.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

applied to mips-fixes.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ