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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210428224624.GD1847222@casper.infradead.org>
Date:   Wed, 28 Apr 2021 23:46:24 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     "Darrick J. Wong" <djwong@...nel.org>
Cc:     linux-kernel@...r.kernel.org,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>, pakki001@....edu,
        gregkh@...uxfoundation.org, arnd@...db.de
Subject: Re: [PATCH] ics932s401: fix broken handling of errors when word
 reading fails

On Wed, Apr 28, 2021 at 03:25:34PM -0700, Darrick J. Wong wrote:
> In commit b05ae01fdb89, someone tried to make the driver handle i2c read
> errors by simply zeroing out the register contents, but for some reason
> left unaltered the code that sets the cached register value the function
> call return value.
> 
> The original patch was authored by a member of the Underhanded
> Mangle-happy Nerds, I'm not terribly surprised.  I don't have the
> hardware anymore so I can't test this, but it seems like a pretty
> obvious API usage fix to me...

Not sure why you cc'd linux-fsdevel, but that's how i got to see it ...

> +++ b/drivers/misc/ics932s401.c
> @@ -134,7 +134,7 @@ static struct ics932s401_data *ics932s401_update_device(struct device *dev)
>  	for (i = 0; i < NUM_MIRRORED_REGS; i++) {
>  		temp = i2c_smbus_read_word_data(client, regs_to_copy[i]);
>  		if (temp < 0)
> -			data->regs[regs_to_copy[i]] = 0;
> +			temp = 0;
>  		data->regs[regs_to_copy[i]] = temp >> 8;
>  	}

Looking at a bit more context in this function, shouldn't we rather clear
'sensors_valid'?  or does it really make sense to pretend we read zero
(rather than 255) from this register?

But then we'd have to actually check sensors_valid in functions like
calculate_src_freq, and i just don't know if it's worthwhile.  Why not
just revert this patch?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ