All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Shivendra Pratap" <shivendra.pratap@oss.qualcomm.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org,
	krzk+dt@kernel.org
Subject: Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
Date: Thu, 14 May 2026 23:19:42 +0000	[thread overview]
Message-ID: <20260514231943.93B30C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260514-arm-psci-system_reset2-vendor-reboots-v22-8-28a5bde07483@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Use-After-Free due to incorrect lifecycle management of non-OF fwnodes using devm_add_action.
--

commit 346fbcb3dbf6a1ca28eec9135059c21e18423182
Author: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>

mfd: core: Add firmware-node support to MFD cells

This commit extends struct mfd_cell with a callback to allow drivers to
provide an explicit firmware node. The node is assigned to the MFD child
device during registration if one is not assigned by other matching
mechanisms.

> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c

[ ... ]

> @@ -224,6 +231,29 @@ static int mfd_add_device(struct device *parent, int id,

[ ... ]

> +			/*
> +			 * platform_device_release() drops only of_node refs.
> +			 * Track non-OF fwnodes explicitly so they are put on
> +			 * all teardown paths.
> +			 */
> +			if (!to_of_node(fwnode)) {
> +				ret = devm_add_action(&pdev->dev,
> +						      mfd_child_fwnode_put,
> +						      fwnode);

Is it safe to tie the fwnode lifetime to the driver bind and unbind
lifecycle using devm_add_action() here?

Since devres managed resources are released when a driver unbinds, if a
driver binds to this MFD child device and is later unbound via sysfs,
device_unbind_cleanup() will call devres_release_all(). This triggers
mfd_child_fwnode_put() and drops the reference, freeing the underlying memory
while the device still has its fwnode pointer populated.

Could a subsequent driver rebind trigger a use-after-free when accessing
the dropped fwnode?

Also, during device removal, device_del() calls devres_release_all() before
emitting the KOBJ_REMOVE uevent. The platform bus uevent handler then accesses
the fwnode:

device_del()
   devres_release_all(dev)
   kobject_uevent(&dev->kobj, KOBJ_REMOVE)
      platform_uevent()
         acpi_device_uevent_modalias()
            ACPI_COMPANION(dev)

Will evaluating ACPI_COMPANION() access dev->fwnode after it has already
been freed by devres_release_all(), causing a use-after-free during
standard device teardown?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514-arm-psci-system_reset2-vendor-reboots-v22-0-28a5bde07483@oss.qualcomm.com?part=8

  reply	other threads:[~2026-05-14 23:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14 14:25 [PATCH v22 00/13] Implement PSCI reboot mode driver for PSCI resets Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 01/13] power: reset: reboot-mode: Remove devres based allocations Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 02/13] power: reset: reboot-mode: Add support for 64 bit magic Shivendra Pratap
2026-05-14 20:15   ` sashiko-bot
2026-05-14 14:25 ` [PATCH v22 03/13] power: reset: reboot-mode: Add support for predefined reboot modes Shivendra Pratap
2026-05-14 21:09   ` sashiko-bot
2026-05-14 14:25 ` [PATCH v22 04/13] firmware: psci: Introduce command-based resets Shivendra Pratap
2026-05-14 21:23   ` sashiko-bot
2026-05-14 14:25 ` [PATCH v22 05/13] mfd: psci-mfd: Add PSCI MFD driver for cpuidle-psci-domain cell Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 06/13] dt-bindings: arm: Document reboot mode magic Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 07/13] power: reset: Add psci-reboot-mode driver Shivendra Pratap
2026-05-14 22:49   ` sashiko-bot
2026-05-14 14:25 ` [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells Shivendra Pratap
2026-05-14 23:19   ` sashiko-bot [this message]
2026-05-14 14:25 ` [PATCH v22 09/13] mfd: psci-mfd: Add psci-reboot-mode child cell Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 10/13] arm64: dts: qcom: Add psci reboot-modes for kodiak boards Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 11/13] arm64: dts: qcom: Add psci reboot-modes for lemans boards Shivendra Pratap
2026-05-14 14:25 ` [PATCH v22 12/13] arm64: dts: qcom: Add psci reboot-modes for monaco boards Shivendra Pratap
2026-05-15  0:24   ` sashiko-bot
2026-05-14 14:25 ` [PATCH v22 13/13] arm64: dts: qcom: Add psci reboot-modes for talos boards Shivendra Pratap

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=20260514231943.93B30C2BCB3@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=shivendra.pratap@oss.qualcomm.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.