All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Wen Yang <wenyang@linux.alibaba.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Arnd Bergmann <arnd@arndb.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] firmware: arm_scmi: avoid double free in error flow
Date: Tue, 26 Nov 2019 10:48:50 +0000	[thread overview]
Message-ID: <20191126104850.GA5784@bogus> (raw)
In-Reply-To: <21f4f7d6-9085-382d-42d3-a63484aca8a2@linux.alibaba.com>

On Tue, Nov 26, 2019 at 06:24:47PM +0800, Wen Yang wrote:
>
>
> On 2019/11/26 12:13 上午, Sudeep Holla wrote:
> > On Mon, Nov 25, 2019 at 11:54:09PM +0800, Wen Yang wrote:
> > > If device_register() fails, both put_device() and kfree()
> > > are called, ending with a double free of the scmi_dev.
> > >
> >
> > Correct.
> >
> > > Calling kfree() is needed only when a failure happens between the
> > > allocation of the scmi_dev and its registration, so move it to
> > > there and remove it from the error flow.
> > >
> >
> > kstrdup_const can fail and in that case device is not yet registered,
> > so we need to free. Since device_register() calls put_device() on failure
> > too, I would just drop it as it's unnecessary, not sure why I have added
> > it in the first place. Can you re-spin the patch dropping put_device
> > and renaming put_dev label to something like free_const.
> >

Please ignore the above completely. I have made some changes locally and
got completely confused when I looked at your patch and compared with
the modified context locally.

>
> Hi Sudeep,
> Thanks for your comments.
> Let's check the code like this:
>
> int device_register(struct device *dev)
> {
>         device_initialize(dev);   --> Initialize kobj-> kref to 1
>         return device_add(dev);
> }
>
> int device_add(struct device *dev)
> {
> ...
>         dev = get_device(dev);  --> kobj-> kref increases by 1
> ...
> done:
>         put_device(dev);  --> kobj-> kref decreases by 1 and is now 1
>         return error;
> ...
> }
>
> So we also need to call put_device (),
> and the original patch should be fine.
> Please kindly help to check again, thank you.
>

You are right, sorry for the confusion. I will apply your original patch.
Thanks again for the patch.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com>
To: Wen Yang <wenyang@linux.alibaba.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH] firmware: arm_scmi: avoid double free in error flow
Date: Tue, 26 Nov 2019 10:48:50 +0000	[thread overview]
Message-ID: <20191126104850.GA5784@bogus> (raw)
In-Reply-To: <21f4f7d6-9085-382d-42d3-a63484aca8a2@linux.alibaba.com>

On Tue, Nov 26, 2019 at 06:24:47PM +0800, Wen Yang wrote:
>
>
> On 2019/11/26 12:13 上午, Sudeep Holla wrote:
> > On Mon, Nov 25, 2019 at 11:54:09PM +0800, Wen Yang wrote:
> > > If device_register() fails, both put_device() and kfree()
> > > are called, ending with a double free of the scmi_dev.
> > >
> >
> > Correct.
> >
> > > Calling kfree() is needed only when a failure happens between the
> > > allocation of the scmi_dev and its registration, so move it to
> > > there and remove it from the error flow.
> > >
> >
> > kstrdup_const can fail and in that case device is not yet registered,
> > so we need to free. Since device_register() calls put_device() on failure
> > too, I would just drop it as it's unnecessary, not sure why I have added
> > it in the first place. Can you re-spin the patch dropping put_device
> > and renaming put_dev label to something like free_const.
> >

Please ignore the above completely. I have made some changes locally and
got completely confused when I looked at your patch and compared with
the modified context locally.

>
> Hi Sudeep,
> Thanks for your comments.
> Let's check the code like this:
>
> int device_register(struct device *dev)
> {
>         device_initialize(dev);   --> Initialize kobj-> kref to 1
>         return device_add(dev);
> }
>
> int device_add(struct device *dev)
> {
> ...
>         dev = get_device(dev);  --> kobj-> kref increases by 1
> ...
> done:
>         put_device(dev);  --> kobj-> kref decreases by 1 and is now 1
>         return error;
> ...
> }
>
> So we also need to call put_device (),
> and the original patch should be fine.
> Please kindly help to check again, thank you.
>

You are right, sorry for the confusion. I will apply your original patch.
Thanks again for the patch.

--
Regards,
Sudeep

  reply	other threads:[~2019-11-26 10:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25 15:54 [PATCH] firmware: arm_scmi: avoid double free in error flow Wen Yang
2019-11-25 15:54 ` Wen Yang
2019-11-25 16:13 ` Sudeep Holla
2019-11-25 16:13   ` Sudeep Holla
2019-11-26 10:24   ` Wen Yang
2019-11-26 10:24     ` Wen Yang
2019-11-26 10:48     ` Sudeep Holla [this message]
2019-11-26 10:48       ` Sudeep Holla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191126104850.GA5784@bogus \
    --to=sudeep.holla@arm.com \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wenyang@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.