From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Daniel Scally <djrscally@gmail.com>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] device property: do not leak child nodes when using NULL/error pointers
Date: Mon, 2 Dec 2024 21:49:06 -0800 [thread overview]
Message-ID: <Z06b0oTvxUi4DTlx@google.com> (raw)
In-Reply-To: <Z0uHJJKMog-REw1D@smile.fi.intel.com>
On Sat, Nov 30, 2024 at 11:44:04PM +0200, Andy Shevchenko wrote:
> On Fri, Nov 29, 2024 at 11:16:54PM -0800, Dmitry Torokhov wrote:
> > On Fri, Nov 29, 2024 at 04:50:15PM +0200, Andy Shevchenko wrote:
> > > On Thu, Nov 28, 2024 at 03:04:50PM -0800, Dmitry Torokhov wrote:
> > > > On Thu, Nov 28, 2024 at 03:13:16PM +0200, Andy Shevchenko wrote:
> > > > > On Wed, Nov 27, 2024 at 09:39:34PM -0800, Dmitry Torokhov wrote:
>
> ...
>
> > > > > > @@ struct fwnode_handle *device_get_next_child_node(const struct device *dev,
> > > > > > const struct fwnode_handle *fwnode = dev_fwnode(dev);
> > > > > > struct fwnode_handle *next;
> > > > >
> > > > > > - if (IS_ERR_OR_NULL(fwnode))
> > > > > > + if (IS_ERR_OR_NULL(fwnode)) {
> > > > > > + fwnode_handle_put(child);
> > > > > > return NULL;
> > > > > > + }
> > > > >
> > > > > > /* Try to find a child in primary fwnode */
> > > > > > next = fwnode_get_next_child_node(fwnode, child);
> > > > >
> > > > > So, why not just moving the original check (w/o dropping the reference) here?
> > > > > Wouldn't it have the same effect w/o explicit call to the fwnode_handle_put()?
> > > >
> > > > Because if you rely on check in fwnode_get_next_child_node() you would
> > > > not know if it returned NULL because there are no more children or
> > > > because the node is invalid. In the latter case you can't dereference
> > > > fwnode->secondary.
> > >
> > > Yes, so, how does it contradict my proposal?
> >
> > I guess I misunderstood your proposal then. Could you please explain it
> > in more detail?
>
>
> Current code (in steps):
> if (IS_ERR_OR_NULL()) check
> trying primary
> trying secondary if previous is NULL
>
>
> My proposal
>
> trying primary
> return if not NULL
> if (IS_ERR_OR_NULL()) check in its current form (no put op)
> trying secondary
>
> After your first patch IIUC this is possible as trying primary will put child uncoditionally.
Ah, I see. No, I do not think this is a good idea: it will make the code
harder to understand for a casual reader: "Why do we check node validity
only after we used it for the first time?"
For the code not in a hot path there is a lot of value in simplicity.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2024-12-03 5:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-28 5:39 [PATCH 1/2] device property: do not leak child nodes when using NULL/error pointers Dmitry Torokhov
2024-11-28 5:39 ` [PATCH 2/2] device property: fix UAF in device_get_next_child_node() Dmitry Torokhov
2024-11-28 13:20 ` Andy Shevchenko
2024-11-28 23:16 ` Dmitry Torokhov
2024-12-09 18:11 ` Andy Shevchenko
2024-11-28 11:49 ` [PATCH 1/2] device property: do not leak child nodes when using NULL/error pointers Greg Kroah-Hartman
2024-11-28 13:13 ` Andy Shevchenko
2024-11-28 23:04 ` Dmitry Torokhov
2024-11-29 14:50 ` Andy Shevchenko
2024-11-30 7:16 ` Dmitry Torokhov
2024-11-30 21:44 ` Andy Shevchenko
2024-12-03 5:49 ` Dmitry Torokhov [this message]
2024-12-03 13:27 ` Andy Shevchenko
2024-12-03 22:45 ` Dmitry Torokhov
2024-12-04 1:16 ` Andy Shevchenko
2024-12-05 20:57 ` Dmitry Torokhov
2024-12-09 18:06 ` Andy Shevchenko
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=Z06b0oTvxUi4DTlx@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=djrscally@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=sakari.ailus@linux.intel.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.