public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: mike.isely@cobaltdigital.com
Cc: Daniel Scally <djrscally@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Mike Isely <isely@pobox.com>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] sofware node: Only the managing device can unreference managed software node
Date: Wed, 25 Feb 2026 13:22:07 +0200	[thread overview]
Message-ID: <aZ7bX4SIoxKTPtoi@smile.fi.intel.com> (raw)
In-Reply-To: <20260224191922.2972974-2-mike.isely@cobaltdigital.com>

On Tue, Feb 24, 2026 at 01:19:22PM -0600, mike.isely@cobaltdigital.com wrote:
> From: Mike Isely <mike.isely@cobaltdigital.com>

Author's and...

> A scenario exists where device_create_managed_software_node() is used
> to create an swnode instance that will be implicitly shared to a child
> device despite best intentions not to permit such sharing (per the
> comment in device_create_managed_software_node()).  I encountered this
> with the sfp kernel module when it was instantiated with properties

SFP? Or is it the name of the actual module in the kernel?

> via a call to platform_device_register_full() - it will create hwmon
> child devices which get all property references.  Unfortunately with
> just a "managed" boolean in struct swnode handling this, then
> kobject_put() gets called for the managed aspect when the child device
> goes away instead of the parent.  This leads to premature freeing of
> the swnode structure, followed by use-after-free problems, heap
> corruption, and generally chaos / crashes / misbehavior in the kernel.
> 
> This commit changes that boolean into a pointer to the actual managing
> struct device, which is then checked against the struct device
> instance that is actually going away (via the usual call back into
> software_node_notify_remove()).  Thus the child device removal is
> ignored as it should, and we only do the kobject_put() when the actual
> managing struct device instance goes away.  We effectively carry a
> little bit more information now so that we can be sure to clean up
> only when the correct struct device instance is actually going away.
> 
> Note that while we are now keeping a pointer to a struct device here,
> this is safe to do because the pointer itself only stays in use while
> the pointed-to device remains valid.  (So no need to be concerned
> about additional reference counting.)

The term is called "object lifetime".

> Signed-off-by: Mike Isely <isely@pobox.com>

...submitter's addresses are different. Either it should be send from the
mentioned address, or you should have

  From: Author <...>
  ...

  SoB: Author <...>
  SoB: Submitter <...>

...

What about the use case (don't know if it's pure theoretical or practical)
when there is a parent and a few children and the managed swnode appears
in one of the children? With some other dependencies between children
it might affect how swnode is get cleaned up. Simple and regular approach
is to cleanup children in the reversed order, but I can't say that it's
always the case. Some children in some corner cases might have their own
dependencies (I saw some strange devices or device drivers where the HW
is a bit complicated and driver is written without much care).

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2026-02-25 11:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24 19:19 [PATCH 0/1] software node: Use-after-free fix in drivers/base/swnode.c mike.isely
2026-02-24 19:19 ` [PATCH 1/1] sofware node: Only the managing device can unreference managed software node mike.isely
2026-02-25 11:22   ` Andy Shevchenko [this message]
2026-02-25 19:42     ` Mike Isely
2026-02-25 20:01       ` Andy Shevchenko
2026-02-25 20:16         ` Mike Isely
2026-02-26  7:16           ` Andy Shevchenko
2026-02-26 19:06             ` Mike Isely
2026-02-26 20:42               ` Andy Shevchenko
2026-02-27 17:55                 ` Mike Isely
2026-02-28 11:02                   ` Andy Shevchenko
2026-02-28 16:34                     ` Mike Isely
2026-02-25  9:46 ` [PATCH 0/1] software node: Use-after-free fix in drivers/base/swnode.c Andy Shevchenko
2026-02-25 18:59   ` Mike Isely
2026-02-25 19:17     ` Andy Shevchenko
2026-02-25 19:48       ` Mike Isely
2026-02-25 20:05         ` 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=aZ7bX4SIoxKTPtoi@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=djrscally@gmail.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=isely@pobox.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.isely@cobaltdigital.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