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

[Bryan O'Donoghue]

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@xxxxxxxxxxxxxx

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