linux-kernel - Re: [PATCH 5.19 0191/1157] hwmon: (sht15) Fix wrong assumptions in device remove callback

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]

Date:   Tue, 16 Aug 2022 12:40:50 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Guenter Roeck <linux@...ck-us.net>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.19 0191/1157] hwmon: (sht15) Fix wrong assumptions in
 device remove callback

On Mon, Aug 15, 2022 at 11:49:11PM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> On Mon, Aug 15, 2022 at 07:52:27PM +0200, Greg Kroah-Hartman wrote:
> > From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
> > 
> > [ Upstream commit 7d4edccc9bbfe1dcdff641343f7b0c6763fbe774 ]
> > 
> > Taking a lock at the beginning of .remove() doesn't prevent new readers.
> > With the existing approach it can happen, that a read occurs just when
> > the lock was taken blocking the reader until the lock is released at the
> > end of the remove callback which then accessed *data that is already
> > freed then.
> > 
> > To actually fix this problem the hwmon core needs some adaption. Until
> > this is implemented take the optimistic approach of assuming that all
> > readers are gone after hwmon_device_unregister() and
> > sysfs_remove_group() as most other drivers do. (And once the core
> > implements that, taking the lock would deadlock.)
> > 
> > So drop the lock, move the reset to after device unregistration to keep
> > the device in a workable state until it's deregistered. Also add a error
> > message in case the reset fails and return 0 anyhow. (Returning an error
> > code, doesn't stop the platform device unregistration and only results
> > in a little helpful error message before the devm cleanup handlers are
> > called.)
> > 
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
> > Link: https://lore.kernel.org/r/20220725194344.150098-1-u.kleine-koenig@pengutronix.de
> > Signed-off-by: Guenter Roeck <linux@...ck-us.net>
> > Signed-off-by: Sasha Levin <sashal@...nel.org>
> 
> Does this mean my concerns I expressed in the mail with Message-Id:
> 20220814155638.idxnihylofsxqlql@...gutronix.de were not taken into
> consideration?

I can't find that message-id on lore.kernel.org, do you have a link?

thanks,

greg k-h