All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Li <Frank.li@oss.nxp.com>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: alexandre.belloni@bootlin.com, Frank.Li@nxp.com,
	linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i3c: master: Fix info leak and UAF in device unregister path
Date: Thu, 23 Jul 2026 14:25:56 -0400	[thread overview]
Message-ID: <amJctAYeAwPdnyeb@lizhi-Precision-Tower-5810> (raw)
In-Reply-To: <20260723075747.34049-1-adrian.hunter@intel.com>

On Thu, Jul 23, 2026 at 10:57:47AM +0300, Adrian Hunter wrote:
> i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before
> calling device_unregister().  During device_unregister(),
> device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while
> the device descriptor is still expected to be valid.  As a result,
> i3c_device_uevent() and a racing modalias_show() can observe a NULL
> desc and fall back to an uninitialized stack struct i3c_device_info,
> leaking kernel stack contents in the generated modalias.  Driver
> .remove() callbacks may also encounter an unexpected NULL desc during
> unbind.
>
> Keep desc valid until device_unregister() has completed.  Since
> device_unregister() drops the device reference and may free the device,
> take an extra reference with get_device() before unregistering.  Clear
> desc afterwards and release the extra reference with put_device().
> This preserves the release-time invariant that desc must be NULL while
> avoiding both the information leak and a potential use-after-free from
> writing desc after the device has been released.
>
> Reported-by: sashiko-bot@kernel.org
> Link: https://lore.kernel.org/linux-i3c/20260702190003.8BF741F000E9@smtp.kernel.org/
> Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure")
> Cc: stable@vger.kernel.org
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> ---

Reviewed-by: Frank Li <Frank.Li@nxp.com>

>  drivers/i3c/master.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index 659c14c2c192..433dc7531701 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
> @@ -3083,11 +3083,12 @@ static void i3c_master_unregister_i3c_devs(struct i3c_master_controller *master)
>  		if (!i3cdev->dev)
>  			continue;
>
> -		i3cdev->dev->desc = NULL;
> -		if (device_is_registered(&i3cdev->dev->dev))
> +		if (device_is_registered(&i3cdev->dev->dev)) {
> +			get_device(&i3cdev->dev->dev);
>  			device_unregister(&i3cdev->dev->dev);
> -		else
> -			put_device(&i3cdev->dev->dev);
> +		}
> +		i3cdev->dev->desc = NULL;
> +		put_device(&i3cdev->dev->dev);
>  		i3cdev->dev = NULL;
>  	}
>  }
> --
> 2.53.0
>

WARNING: multiple messages have this Message-ID (diff)
From: Frank Li <Frank.li@oss.nxp.com>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: alexandre.belloni@bootlin.com, Frank.Li@nxp.com,
	linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i3c: master: Fix info leak and UAF in device unregister path
Date: Thu, 23 Jul 2026 14:25:56 -0400	[thread overview]
Message-ID: <amJctAYeAwPdnyeb@lizhi-Precision-Tower-5810> (raw)
In-Reply-To: <20260723075747.34049-1-adrian.hunter@intel.com>

On Thu, Jul 23, 2026 at 10:57:47AM +0300, Adrian Hunter wrote:
> i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before
> calling device_unregister().  During device_unregister(),
> device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while
> the device descriptor is still expected to be valid.  As a result,
> i3c_device_uevent() and a racing modalias_show() can observe a NULL
> desc and fall back to an uninitialized stack struct i3c_device_info,
> leaking kernel stack contents in the generated modalias.  Driver
> .remove() callbacks may also encounter an unexpected NULL desc during
> unbind.
>
> Keep desc valid until device_unregister() has completed.  Since
> device_unregister() drops the device reference and may free the device,
> take an extra reference with get_device() before unregistering.  Clear
> desc afterwards and release the extra reference with put_device().
> This preserves the release-time invariant that desc must be NULL while
> avoiding both the information leak and a potential use-after-free from
> writing desc after the device has been released.
>
> Reported-by: sashiko-bot@kernel.org
> Link: https://lore.kernel.org/linux-i3c/20260702190003.8BF741F000E9@smtp.kernel.org/
> Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure")
> Cc: stable@vger.kernel.org
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> ---

Reviewed-by: Frank Li <Frank.Li@nxp.com>

>  drivers/i3c/master.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index 659c14c2c192..433dc7531701 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
> @@ -3083,11 +3083,12 @@ static void i3c_master_unregister_i3c_devs(struct i3c_master_controller *master)
>  		if (!i3cdev->dev)
>  			continue;
>
> -		i3cdev->dev->desc = NULL;
> -		if (device_is_registered(&i3cdev->dev->dev))
> +		if (device_is_registered(&i3cdev->dev->dev)) {
> +			get_device(&i3cdev->dev->dev);
>  			device_unregister(&i3cdev->dev->dev);
> -		else
> -			put_device(&i3cdev->dev->dev);
> +		}
> +		i3cdev->dev->desc = NULL;
> +		put_device(&i3cdev->dev->dev);
>  		i3cdev->dev = NULL;
>  	}
>  }
> --
> 2.53.0
>

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

  reply	other threads:[~2026-07-23 18:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-23  7:57 [PATCH] i3c: master: Fix info leak and UAF in device unregister path Adrian Hunter
2026-07-23  7:57 ` Adrian Hunter
2026-07-23 18:25 ` Frank Li [this message]
2026-07-23 18:25   ` Frank Li

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=amJctAYeAwPdnyeb@lizhi-Precision-Tower-5810 \
    --to=frank.li@oss.nxp.com \
    --cc=Frank.Li@nxp.com \
    --cc=adrian.hunter@intel.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.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.