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: Thu, 28 Nov 2024 15:04:50 -0800 [thread overview]
Message-ID: <Z0j3EtRmYBmGFApu@google.com> (raw)
In-Reply-To: <Z0hsbNqXSkQjsR1v@smile.fi.intel.com>
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:
> > The documentation to various API calls that locate children for a given
> > fwnode (such as fwnode_get_next_available_child_node() or
> > device_get_next_child_node()) states that the reference to the node
> > passed in "child" argument is dropped unconditionally, however the
> > change that added checks for the main node to be NULL or error pointer
> > broke this promise.
>
> This commit message doesn't explain a use case. Hence it might be just
> a documentation issue, please elaborate.
I do not have a specific use case in mind, however the implementation
behavior does not match the stated one, and so it makes sense to get it
fixed. Otherwise callers would have to add checks to conditionally drop
the reference to "child" argument in certain cases, which will
complicate caller's code.
>
> > Add missing fwnode_handle_put() calls to restore the documented
> > behavior.
>
> ...
>
> While at it, please fix the kernel-doc (missing Return section).
OK.
>
> > {
> > + if (IS_ERR_OR_NULL(fwnode) ||
>
> Unneeded check as fwnode_has_op() has it already.
Yes, it has, but that is not obvious nor it is a documented behavior of
fwnode_has_op(). It also different semantics: it checks whether a fwnode
implements a given operation, not whether fwnode is valid. That check is
incidental in fwnode_has_op().
They all are macros so compiler should collapse duplicate checks, but if
you feel really strongly about it I can drop IS_ERR_OR_NULL() check.
>
> > + !fwnode_has_op(fwnode, get_next_child_node)) {
> > + fwnode_handle_put(child);
> > + return NULL;
> > + }
>
> > return fwnode_call_ptr_op(fwnode, get_next_child_node, child);
>
> Now it's useless to call the macro, you can simply take the direct call.
OK, will change to a direct call.
>
> > }
>
> ...
>
> > @@ 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.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2024-11-28 23:04 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 [this message]
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
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=Z0j3EtRmYBmGFApu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox