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] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 15 Aug 2022 23:49:11 +0200
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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

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?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ