linux-kernel - Re: [PATCH v2] iio: trigger: Fix error handling in viio_trigger

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] [day] [month] [year] [list]

Message-ID: <20251109135036.4c05833b@jic23-huawei>
Date: Sun, 9 Nov 2025 13:50:36 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Ma Ke <make24@...as.ac.cn>, dlechner@...libre.com, nuno.sa@...log.com,
 andy@...nel.org, error27@...il.com, andriy.shevchenko@...el.com,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 akpm@...ux-foundation.org, stable@...r.kernel.org
Subject: Re: [PATCH v2] iio: trigger: Fix error handling in
 viio_trigger_alloc

On Thu, 6 Nov 2025 18:16:06 +0300
Dan Carpenter <dan.carpenter@...aro.org> wrote:

> On Thu, Nov 06, 2025 at 04:29:23PM +0800, Ma Ke wrote:
> > ---
> > Changes in v2:
> > - modified the patch, thanks for developer's suggestions.
> > ---
> >  drivers/iio/industrialio-trigger.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c
> > index 54416a384232..9f6d30a244d9 100644
> > --- a/drivers/iio/industrialio-trigger.c
> > +++ b/drivers/iio/industrialio-trigger.c
> > @@ -524,6 +524,7 @@ static void iio_trig_release(struct device *device)
> >  			       CONFIG_IIO_CONSUMERS_PER_TRIGGER);
> >  	}
> >  	kfree(trig->name);
> > +	mutex_destroy(&trig->pool_lock);
> >  	kfree(trig);
> >  }
> >  
> > @@ -596,8 +597,9 @@ struct iio_trigger *viio_trigger_alloc(struct device *parent,
> >  
> >  free_descs:
> >  	irq_free_descs(trig->subirq_base, CONFIG_IIO_CONSUMERS_PER_TRIGGER);
> > +	trig->subirq_base = 0;  
> 
> This doesn't work.  Do it before the goto.

This is a bit ugly however we do it. Maybe should just call
device_initialize() to hand over to the reference counted version much later?
Just before return trig seems easiest spot to reason about.

That seems nicer than doing an irq_get_chip() in iio_trig_release() to figure
out if the first part of the if (trig->subirq_base) conditional block should run or not.

Adding a flag to the trig structure just to indicate we got to running
that loop also feels annoying but at least would ensure we could just do
a put_device() in here without the other handling above.

> 
> regards,
> dan carpenter
> 
> >  free_trig:
> > -	kfree(trig);
> > +	put_device(&trig->dev);
> >  	return NULL;
> >  }
> >  
> > -- 
> > 2.17.1