On Tue, Oct 24, 2023 at 11:57:05AM +0300, Dan Carpenter wrote:
> On Tue, Oct 24, 2023 at 10:42:48AM +0200, Amelie Delaunay wrote:
> > Hi Dan,
> >
> > On 10/24/23 07:01, Dan Carpenter wrote:
> > > The put_device(&stm->dev) call will trigger stm_device_release() which
> > > frees "stm" so the vfree(stm) on the next line is a double free.
> > >
> > > Fixes: 389b6699a2aa ("stm class: Fix stm device initialization order")
> > > Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> > > ---
> > > drivers/hwtracing/stm/core.c | 10 +++++-----
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
> > > index 534fbefc7f6a..7315f7d3910d 100644
> > > --- a/drivers/hwtracing/stm/core.c
> > > +++ b/drivers/hwtracing/stm/core.c
> > > @@ -868,8 +868,10 @@ int stm_register_device(struct device *parent, struct stm_data *stm_data,
> > > return -ENOMEM;
> > > stm->major = register_chrdev(0, stm_data->name, &stm_fops);
> > > - if (stm->major < 0)
> > > - goto err_free;
> > > + if (stm->major < 0) {
> > > + vfree(stm);
> > > + return stm->major;
> >
> > isn't there a use-after-free of stm here?
> >
>
> Oh crap. How did I not catch that before sending... :( Sorry!
> Thanks for catching this. I will investigate my QC process and resend.
The problem is that I run my devel version of Smatch which just prints
and overwhelming amount of nonsense so I missed the bug in the noise.
This isn't the first time this has been an issue. :( I've changed my
QC scripts to run the devel version and the released version.
regards,
dan carpenter
