Messages in this thread | | | Subject | Re: [PATCH 0/8] counter: Remove struct counter_device::priv | From | Lars-Peter Clausen <> | Date | Tue, 21 Dec 2021 13:04:50 +0100 |
| |
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: >> On 12/21/21 11:45 AM, Uwe Kleine-König wrote: >>> similar to patch >>> https://lore.kernel.org/r/4bde7cbd9e43a5909208102094444219d3154466.1640072891.git.vilhelm.gray@gmail.com >>> 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. > >> 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.
> >> 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 :-\
| |