Re: [PATCH 3/3] media: iris: Fix use-after-free on unbind with open sessions

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 09/11/2026 05:08, Vishnu Reddy wrote:
>>> +static void iris_core_release(struct v4l2_device *v4l2_dev)
>>> +{
>>> +    struct iris_core *core = container_of(v4l2_dev, struct iris_core,
>>> v4l2_dev);
>>> +
>>> +    mutex_destroy(&core->lock);
>>> +    put_device(core->dev);
>>> +    kfree(core);
>>> +}
>>> +
>> What you would have here is an admixture of devm allocated stuff and
>> hand-allocated, refcounted with custom v4l2_release() which might all work
>> but, it's not obvious to me does work i.e. core is hand allocated while
>> reg_base, response_packet etc are devm() managed.
> reg_base and response_packet are safe: after iris_remove() the IRQ is
> freed and the core is in IRIS_CORE_DEINIT, so nothing uses them. Only
> the core structure must outlive remove(), so only that is refcounted.

Right and you can confidently assert that for clocks, regulators, power 
domains and ICC ?

TBH I think this is pretty hacky and unlikely to be safe.

Another way I don't think this approach works is an ioctl() waiting on 
firmware do do whatever. If the ioctl wakes up after the devres() 
removal - then what ?

>> A much simpler solution to your problem is :
>>
>> static struct platform_driver iris_driver = {
>>      .driver = {
>>          .suppress_bind_attrs = true,
>>          ...
>>      },
>> };
>>
> This was discussed in [1]. Dmitry noted it is a sign of a badly written driver,
> and I agree: it removes the unbind interface to avoid the problem instead of
> fixing remove().
> 
> [1]
> https://lore.kernel.org/all/ 
> CAO9ioeUvV+3sME9P1bJTpDOSty=uojOKak659XCf337++vPVNg@mail.gmail.com

In which case I think you need to do more poving/reasoning here about 
admixture of devm and hand-rolled allocations.

Like what's the use-case you are supporting here with the unbind exactly ?

---
bod