All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Lorenzo Bianconi" <lorenzo.bianconi@oss.qualcomm.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH 2/2] PCI/pwrctrl: tc9563: use devm-managed I2C dummy device allocation
Date: Wed, 29 Jul 2026 13:44:01 +0000	[thread overview]
Message-ID: <20260729134401.8EAD31F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260729-pci-pwrctrl-tc956x-regmap-v1-2-20ce61a3ce12@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Use-After-Free due to teardown order inversion between i2c_put_adapter() and devm-managed dummy client release.
--

--- Patch [2]: [PATCH 2/2] PCI/pwrctrl: tc9563: use devm-managed I2C dummy device allocation ---
commit f54ecfd3f2485cf33e559cd8f58fa24de337138b
Author: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>

PCI/pwrctrl: tc9563: use devm-managed I2C dummy device allocation

This patch converts the driver to use devm_i2c_new_dummy_device to manage
the I2C dummy client. It removes the manual i2c_unregister_device calls
from the probe error path and the remove function.

> diff --git a/drivers/pci/pwrctrl/pci-pwrctrl-tc9563.c b/drivers/pci/pwrctrl/pci-pwrctrl-tc9563.c
> index 8bccf3abd1892..5b05e76f6c80d 100644
> --- a/drivers/pci/pwrctrl/pci-pwrctrl-tc9563.c
> +++ b/drivers/pci/pwrctrl/pci-pwrctrl-tc9563.c
[ ... ]
> @@ -607,7 +606,6 @@ static int tc9563_pwrctrl_probe(struct platform_device *pdev)
>  power_off:
>  	tc9563_pwrctrl_power_off(&tc9563->pwrctrl);
>  remove_i2c:
> -	i2c_unregister_device(tc9563->client);
>  	i2c_put_adapter(tc9563->adapter);
>  	return ret;
>  }

[Severity: High]
Will this cause a use-after-free by changing the teardown order?

By switching to devm_i2c_new_dummy_device, the dummy client is now
unregistered by devres cleanup, which executes after tc9563_pwrctrl_probe
returns. 

Because i2c_put_adapter is still called manually before returning, the
adapter reference is dropped before devres unregisters the dummy client. If
dropping this reference allows the adapter to be freed concurrently, it would
forcibly unregister all children. When devres later attempts to unregister
the client, it would operate on an already-freed pointer.

Could devm_add_action_or_reset be used to manage the i2c_put_adapter call
so the teardown sequence happens in the correct reverse order?

[ ... ]
> @@ -619,7 +617,6 @@ static void tc9563_pwrctrl_remove(struct platform_device *pdev)
>  					struct tc9563_pwrctrl, pwrctrl);
>  
>  	tc9563_pwrctrl_power_off(&tc9563->pwrctrl);
> -	i2c_unregister_device(tc9563->client);
>  	i2c_put_adapter(tc9563->adapter);
>  }

[Severity: High]
Does this also expose driver unbind to the same teardown order inversion?

Since tc9563_pwrctrl_remove executes before devres cleanup, dropping the
adapter reference here deterministically happens before the dummy client is
unregistered.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729-pci-pwrctrl-tc956x-regmap-v1-0-20ce61a3ce12@oss.qualcomm.com?part=2

  reply	other threads:[~2026-07-29 13:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 13:34 [PATCH 0/2] Rely on regmap APIs in tc9563 PCI/pwrctrl driver Lorenzo Bianconi
2026-07-29 13:34 ` [PATCH 1/2] PCI/pwrctrl: tc9563: rely on regmap APIs Lorenzo Bianconi
2026-07-29 13:43   ` sashiko-bot
2026-07-29 14:42   ` Manivannan Sadhasivam
2026-07-29 13:34 ` [PATCH 2/2] PCI/pwrctrl: tc9563: use devm-managed I2C dummy device allocation Lorenzo Bianconi
2026-07-29 13:44   ` sashiko-bot [this message]
2026-07-29 14:03     ` Lorenzo Bianconi
2026-07-29 14:43   ` Manivannan Sadhasivam

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=20260729134401.8EAD31F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.bianconi@oss.qualcomm.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.