Re: [PATCH 0/8] counter: Remove struct counter_device::priv
From: Lars-Peter Clausen <lars@metafoo.de>
Date: 2021-12-21 12:05:10
Also in:
linux-iio, lkml
On 12/21/21 12:35 PM, Uwe Kleine-König wrote:
Hello Lars, On Tue, Dec 21, 2021 at 12:12:12PM +0100, Lars-Peter Clausen wrote:quoted
On 12/21/21 11:45 AM, Uwe Kleine-König wrote:quoted
similar to patch https://lore.kernel.org/r/4bde7cbd9e43a5909208102094444219d3154466.1640072891.git.vilhelm.gray@gmail.com (local) the usage of struct counter_device::priv can be replaced by container_of which improves type safety and code size. This series depends on above patch, converts the remaining drivers and finally drops struct counter_device::priv.Not sure if this is such a good idea. struct counter_device should not be embedded in the drivers state struct in the first place.Just to mention it: My patch series didn't change this, this was already broken before.
I know, but this series has to be reverted when the framework is fixed.
quoted
struct counter_device contains a struct device, which is a reference counted object. But by embedding it in the driver state struct the life time of both the struct counter_device and and struct device are bound to the life time of the driver state struct. Which means the struct device memory can get freed before the last reference is dropped, which leads to a use-after-free and undefined behavior.Well, the driver struct is allocated using devm_kzalloc for all drivers.
devm_kzalloc() doesn't make a difference. The managed memory is freed when the parent device is unbound/removed. There may very well be reference to the counter_device at this point.
So I think it's not *very* urgent to fix. Still you're right, this should be addressed.
Yes and no, this can trivially be used for privilege escalation, but then again on systems with a counter_device probably everything runs as root anyway.
quoted
The framework should be changed to rather then embedding the struct counter_device in the state struct to just have a pointer to it. With the struct counter_device having its own allocation that will be freed when the last reference to the struct device is dropped.My favourite would be to implement a counter_device_alloc / counter_device_add approach, similar to what spi_alloc_controller and alloc_etherdev do. The downside is that this isn't typesafe either :-\
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel