All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Chen-Yu Tsai" <wenst@chromium.org>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 02/16] device property: Add fwnode_graph_get_next_port_endpoint()
Date: Wed, 10 Jun 2026 08:57:27 +0000	[thread overview]
Message-ID: <20260610085727.7A20B1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260610084053.2059858-3-wenst@chromium.org>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] The local variable `ep` is declared but never used in `fwnode_graph_get_next_port_endpoint()`.

Pre-existing issues:
- [High] Preexisting Use-After-Free, Double-Free, Memory Leak, and Infinite Loop in `fwnode_get_next_child_node()` when crossing from primary to secondary fwnodes.
--

commit ef024cc56635ec6ba836569acc9c332f8f2249dc
Author: Chen-Yu Tsai <wenst@chromium.org>

device property: Add fwnode_graph_get_next_port_endpoint()

This commit introduces fwnode_graph_get_next_port_endpoint(), a new helper
function that allows consumers to find endpoint nodes under a given port
firmware node. It iterates over the child nodes of the port, checking if
their name matches "endpoint", and returns the matching node.

> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 8cbf33f3a9428..badb49ac3d8a4 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c

[ ... ]

> @@ -1099,6 +1099,39 @@ int fwnode_irq_get_byname(const struct fwnode_handle *fwnode, const char *name)
>  }
>  EXPORT_SYMBOL(fwnode_irq_get_byname);
>  
> +/**
> + * fwnode_graph_get_next_port_endpoint - Get next endpoint firmware node in port
> + * @port: Pointer to the target port firmware node
> + * @prev: Previous endpoint node or %NULL to get the first
> + *
> + * The caller is responsible for calling fwnode_handle_put() on the returned
> + * fwnode pointer. Note that this function also puts a reference to @prev
> + * unconditionally.
> + *
> + * Return: an endpoint firmware node pointer or %NULL if no more endpoints
> + * are available.
> + */
> +struct fwnode_handle *fwnode_graph_get_next_port_endpoint(const struct fwnode_handle *port,
> +							  struct fwnode_handle *prev)
> +{
> +	struct fwnode_handle *ep;

[Severity: Low]
Are there plans to use this local variable later? It appears to be declared
here but never used, which could cause a compiler warning.

> +
> +	while (1) {
> +		prev = fwnode_get_next_child_node(port, prev);

[Severity: High]
This is a pre-existing issue, but does calling fwnode_get_next_child_node()
here expose a use-after-free and double-free when crossing from primary to
secondary fwnodes?

If a fwnode has both primary (OF) and secondary (swnode) children:

1. When reaching the end of the primary OF children,
of_fwnode_get_next_child_node() drops the reference to the last OF child
and returns NULL.

2. fwnode_get_next_child_node() then delegates to the secondary ops
(software_node_get_next_child), passing the exact same child pointer.

Since the OF node was already put, the secondary ops access freed memory
when checking if the child is a software node, causing a use-after-free.

3. software_node_get_next_child() then unconditionally calls
fwnode_handle_put(child), triggering a double-free.

4. It then returns the first secondary software node. On the next iteration,
the caller passes this swnode back.

The primary OF ops evaluate to_of_node(swnode) as NULL, which causes
of_get_next_available_child() to restart iteration and return the first
OF child again. It also fails to put the swnode, causing a memory leak.

Could this create an infinite loop alternating between the first OF child
and the first software node, repeatedly triggering the use-after-free and
double-free on every cycle?

> +		if (!prev)
> +			break;
> +
> +		if (WARN(!fwnode_name_eq(prev, "endpoint"),
> +			 "non endpoint node is used (%pfw)", prev))
> +			continue;
> +
> +		break;
> +	}
> +
> +	return prev;
> +}
> +EXPORT_SYMBOL_GPL(fwnode_graph_get_next_port_endpoint);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610084053.2059858-1-wenst@chromium.org?part=2

  reply	other threads:[~2026-06-10  8:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-10  8:40 [PATCH v2 00/16] arm64: mediatek: Add M.2 E-key slot on Chromebooks Chen-Yu Tsai
2026-06-10  8:40 ` [PATCH v2 01/16] device property: Add fwnode_graph_get_port_by_id() Chen-Yu Tsai
2026-06-10  8:55   ` sashiko-bot
2026-06-10 13:57   ` Andy Shevchenko
2026-06-10  8:40 ` [PATCH v2 02/16] device property: Add fwnode_graph_get_next_port_endpoint() Chen-Yu Tsai
2026-06-10  8:57   ` sashiko-bot [this message]
2026-06-10 14:08   ` Andy Shevchenko
2026-06-10  8:40 ` [PATCH v2 03/16] power: sequencing: Change CONFIG_POWER_SEQUENCING to bool Chen-Yu Tsai
2026-06-10  8:55   ` sashiko-bot
2026-06-10  9:00   ` Chen-Yu Tsai
2026-06-10  8:40 ` [PATCH v2 04/16] usb: hub: Return actual error from hub_configure() in hub_probe() Chen-Yu Tsai
2026-06-10 14:20   ` Andy Shevchenko
2026-06-10  8:40 ` [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device Chen-Yu Tsai
2026-06-10  8:56   ` sashiko-bot
2026-06-10 14:16   ` Andy Shevchenko
2026-06-10  8:40 ` [PATCH v2 06/16] usb: hub: Pass |struct usb_port*| to usb_port_is_power_on() Chen-Yu Tsai
2026-06-10  8:40 ` [PATCH v2 07/16] usb: hub: Power on connected M.2 E-key connectors Chen-Yu Tsai
2026-06-10  9:03   ` sashiko-bot
2026-06-10 14:31   ` Andy Shevchenko
2026-06-10  8:40 ` [PATCH v2 08/16] Revert "dt-bindings: usb: mediatek,mtk-xhci: Add port for SuperSpeed EP" Chen-Yu Tsai
2026-06-10  8:40 ` [PATCH v2 09/16] dt-bindings: usb: mediatek,mtk-xhci: Allow ports for USB connections Chen-Yu Tsai
2026-06-10  8:40 ` [PATCH v2 10/16] power: sequencing: pcie-m2: support matching on remote "port" node Chen-Yu Tsai
2026-06-10 14:33   ` Andy Shevchenko
2026-06-10  8:40 ` [PATCH v2 11/16] power: sequencing: pcie-m2: Add usb and sdio targets for E-key connector Chen-Yu Tsai
2026-06-10 14:36   ` Andy Shevchenko
2026-06-10  8:40 ` [PATCH v2 12/16] arm64: dts: mediatek: mt8192-asurada: Add USB type-A connector Chen-Yu Tsai
2026-06-10  8:40 ` [PATCH v2 13/16] arm64: dts: mediatek: mt8192-asurada: Add M.2 E-key slot Chen-Yu Tsai
2026-06-10  8:40 ` [PATCH v2 14/16] arm64: dts: mediatek: mt8195-cherry: " Chen-Yu Tsai
2026-06-10  9:03   ` sashiko-bot
2026-06-10  8:40 ` [PATCH v2 15/16] arm64: dts: mediatek: mt8195-cherry: Add USB type-A connector Chen-Yu Tsai
2026-06-10  8:40 ` [PATCH v2 16/16] arm64: dts: mediatek: mt8188-geralt: Add WiFi/BT as M.2 E-key slot Chen-Yu Tsai
2026-06-10  9:02   ` sashiko-bot

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=20260610085727.7A20B1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wenst@chromium.org \
    /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.