All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Wentao Liang" <vulab@iscas.ac.cn>, chengzhihao1@huawei.com
Cc: richard@nod.at, daniel@makrotopia.org,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	vigneshr@ti.com, miquel.raynal@bootlin.com,
	stable@vger.kernel.org
Subject: Re: [PATCH] mtd: ubi: Fix UBI device reference leak in ubi_detach_mtd_dev()
Date: Thu, 17 Sep 2026 10:40:29 +0000	[thread overview]
Message-ID: <20260917104030.223651F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260917103102.2147038-1-vulab@iscas.ac.cn>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mtd: ubi: double put of ubi_device in ubi_detach_mtd_dev()
--

commit dc1e1560c6a92e217dc3827eb13a6c41acadcafb
Author: Wentao Liang <vulab@iscas.ac.cn>

mtd: ubi: Fix UBI device reference leak in ubi_detach_mtd_dev()

ubi_detach_mtd_dev() takes a reference on the UBI device with ubi_get_device()
and attempts to drop it. This patch aims to fix a reference leak when returning
-EBUSY.

> diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
> index a901f8edfa41d..866638c006494 100644
> --- a/drivers/mtd/ubi/build.c
> +++ b/drivers/mtd/ubi/build.c
> @@ -1073,6 +1073,7 @@ int ubi_detach_mtd_dev(int ubi_num, int anyway)
>  	if (ubi->ref_count) {
>  		if (!anyway) {
>  			spin_unlock(&ubi_devices_lock);
> +			put_device(&ubi->dev);

[Severity: High]
Does this code double-put the ubi_device on the error path?

Looking at ubi_detach_mtd_dev() in drivers/mtd/ubi/build.c, put_device() is
already called right before the ref_count check:

	spin_lock(&ubi_devices_lock);
	put_device(&ubi->dev);
	ubi->ref_count -= 1;
	if (ubi->ref_count) {
		if (!anyway) {
			spin_unlock(&ubi_devices_lock);

Adding another put_device(&ubi->dev) here drops a kobject reference that the
function does not own, leading to premature freeing of struct ubi_device memory
via dev_release while it is still in use by other kernel components.

If a user with CAP_SYS_RESOURCE calls the UBI_IOCDET ioctl on the UBI control
device while the target UBI device is in use, ubi->ref_count is > 0, leading
ubi_detach_mtd_dev() to return -EBUSY and execute this path.

This appears to be a flawed backport intended for a newer kernel tree where
put_device() was actually missing from this block (due to commit 7e84c961b2eb).
In this baseline, the reference is already correctly dropped before the -EBUSY
check.

>  			return -EBUSY;
>  		}
>  		/* This may only happen if there is a bug */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917103102.2147038-1-vulab@iscas.ac.cn?part=1

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2026-09-17 10:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17 10:31 [PATCH] mtd: ubi: Fix UBI device reference leak in ubi_detach_mtd_dev() Wentao Liang
2026-09-17 10:40 ` sashiko-bot [this message]
2026-09-17 11:20 ` Zhihao Cheng

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=20260917104030.223651F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=chengzhihao1@huawei.com \
    --cc=daniel@makrotopia.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=vigneshr@ti.com \
    --cc=vulab@iscas.ac.cn \
    /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.