All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sebastian Reichel" <sebastian.reichel@collabora.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH 1/8] usb: typec: tcpm: allocate pd_list entries non device managed
Date: Fri, 13 Nov 2026 16:55:17 +0000	[thread overview]
Message-ID: <sashiko-outbox-213249@kernel.org> (raw)
In-Reply-To: <20261113-fusb302-probe-cleanup-v1-1-e5c65a8c58c8@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] usb: typec: tcpm: leak of pd_list entries on
  tcpm_fw_get_caps() error paths
It also noticed 1 related pre-existing issue this patch does not
introduce:
- [Medium] usb: typec: tcpm: fwnode reference leak in tcpm_fw_get_caps()
  [1]
--

commit b86bde7535f2bafb293f7e234db00124b8e22755
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

usb: typec: tcpm: allocate pd_list entries non device managed

This commit replaces devm_kzalloc_obj() and devm_kfree() with unmanaged
kzalloc_obj() and kfree() for port->pd_list[i] allocations.

> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index bb90211660cae..07d2a03d2b8d7 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c

[ ... ]

> @@ -8391,7 +8391,7 @@ static int tcpm_fw_get_caps(struct tcpm_port *port, struct fwnode_handle *fwnode
>  	}
>  
>  	for (i = 0; i < port->pd_count; i++) {
> -		port->pd_list[i] = devm_kzalloc_obj(port->dev, struct pd_data);
> +		port->pd_list[i] = kzalloc_obj(*port->pd_list[i]);
>  		if (!port->pd_list[i]) {
>  			ret = -ENOMEM;
>  			goto put_capabilities;

[Severity: Medium]
Does switching port->pd_list[i] to unmanaged kzalloc_obj() leak those
entries when tcpm_fw_get_caps() or tcpm_register_port() fails?

In tcpm_fw_get_caps(), neither put_caps nor put_capabilities frees already
allocated port->pd_list[0..i] entries if a later loop iteration or PDO
validation fails.  Even when tcpm_fw_get_caps() succeeds,
tcpm_port_unregister_pd() (where kfree(port->pd_list[i]) runs) is only
reached via out_unregister_pd at the end of tcpm_register_port(), so earlier
failures such as -EPROBE_DEFER from usb_role_switch_get() jump to
out_destroy_wq or out_role_sw_put and leak port->pd_list[i]:

drivers/usb/typec/tcpm/tcpm.c:tcpm_register_port() {
    ...
	if (IS_ERR(port->role_sw)) {
		err = PTR_ERR(port->role_sw);
		goto out_destroy_wq;
	}

	err = devm_tcpm_psy_register(port);
	if (err)
		goto out_role_sw_put;
    ...
out_unregister_pd:
	tcpm_port_unregister_pd(port);
out_role_sw_put:
	usb_role_switch_put(port->role_sw);
out_destroy_wq:
	tcpm_debugfs_exit(port);
	kthread_destroy_worker(port->wq);
	return ERR_PTR(err);
}

[Severity: Medium]
This problem wasn't introduced by this patch, but jumping to
put_capabilities when kzalloc_obj() fails on iteration i > 0 leaks the caps
fwnode reference [1] acquired by fwnode_get_next_child_node() in the
previous iteration, because it bypasses put_caps where fwnode_handle_put(caps)
is called.

[1] https://sashiko.dev/#/bug/linux-d106a4e9-4871-4f7c-8575-50cb448be123

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261113-fusb302-probe-cleanup-v1-0-e5c65a8c58c8@collabora.com?part=1

  reply	other threads:[~2026-11-13 16:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 16:42 [PATCH 0/8] usb: typec: fusb302: cleanup device driver probe Sebastian Reichel
2026-11-13 16:42 ` [PATCH 1/8] usb: typec: tcpm: allocate pd_list entries non device managed Sebastian Reichel
2026-11-13 16:55   ` sashiko-bot [this message]
2026-11-13 16:42 ` [PATCH 2/8] usb: typec: tcpm: add device managed port registration Sebastian Reichel
2026-11-13 17:06   ` sashiko-bot
2026-11-13 16:42 ` [PATCH 3/8] usb: typec: fusb302: Switch to device managed resources Sebastian Reichel
2026-11-13 17:21   ` sashiko-bot
2026-11-13 16:42 ` [PATCH 4/8] usb: typec: fusb302: switch to devm_pm_set_wake_irq Sebastian Reichel
2026-11-13 17:34   ` sashiko-bot
2026-11-13 16:42 ` [PATCH 5/8] usb: typec: fusb302: rename init_gpio into fusb302_init_irq Sebastian Reichel
2026-11-13 17:35   ` sashiko-bot
2026-11-13 16:42 ` [PATCH 6/8] usb: typec: fusb302: move gpio_int_n into function local scope Sebastian Reichel
2026-11-13 17:36   ` sashiko-bot
2026-11-13 16:42 ` [PATCH 7/8] usb: typec: fusb302: rework gpio_int_n_irq handling Sebastian Reichel
2026-11-13 17:41   ` sashiko-bot
2026-11-13 16:42 ` [PATCH 8/8] usb: typec: fusb302: drop custom gpio interrupt logic Sebastian Reichel
2026-11-13 17:51   ` 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=sashiko-outbox-213249@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sebastian.reichel@collabora.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.