mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zhihao Cheng <chengzhihao1@huawei.com>
To: Daniel Golle <daniel@makrotopia.org>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>
Subject: Re: [PATCH 1/4] mtd: ubi: block: don't return on error when removing
Date: Wed, 3 May 2023 21:09:49 +0800	[thread overview]
Message-ID: <89f2a4a9-6054-80a8-285f-2be6c57c299d@huawei.com> (raw)
In-Reply-To: <4bca8ffa66fa094da37625e66f3a2681058531d6.1683043928.git.daniel@makrotopia.org>

在 2023/5/3 0:48, Daniel Golle 写道:
> There is no point on returning the error from ubiblock_remove in case
> it is being called due to a volume removal event -- the volume is gone,
> we should destroy and remove the ubiblock device no matter what.
> 
> Introduce a new boolean parameter 'force' to tell ubiblock_remove to go
> on even in case the ubiblock device is still busy. Use that new option
> when calling ubiblock_remove due to a UBI_VOLUME_REMOVED event.
> 
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
>   drivers/mtd/ubi/block.c | 6 +++---
>   drivers/mtd/ubi/cdev.c  | 2 +-
>   drivers/mtd/ubi/ubi.h   | 4 ++--
>   3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
> index 3711d7f746003..6f5804f4b8f55 100644
> --- a/drivers/mtd/ubi/block.c
> +++ b/drivers/mtd/ubi/block.c
> @@ -457,7 +457,7 @@ static void ubiblock_cleanup(struct ubiblock *dev)
>   	idr_remove(&ubiblock_minor_idr, dev->gd->first_minor);
>   }
>   
> -int ubiblock_remove(struct ubi_volume_info *vi)
> +int ubiblock_remove(struct ubi_volume_info *vi, bool force)
>   {
>   	struct ubiblock *dev;
>   	int ret;
> @@ -471,7 +471,7 @@ int ubiblock_remove(struct ubi_volume_info *vi)
>   
>   	/* Found a device, let's lock it so we can check if it's busy */
>   	mutex_lock(&dev->dev_mutex);
> -	if (dev->refcnt > 0) {
> +	if (dev->refcnt > 0 && !force) {
>   		ret = -EBUSY;
>   		goto out_unlock_dev;
>   	}

After looking through this series, I think we should pay attention to 
one problem: The lifetime of mtd device and ubi things(ubi 
device/volume/block device). It's difficult to decide whether or not to 
destroy ubi things when mtd driver is removed.
If we destroy ubi things, one application may have opened an ubi volume 
early, then ubi device and all its volumes are destroyed by 
ubi_notify_remove(), later volume accessing by the application will 
trigger an UAF problem in kernel.
       App              driver_remove
fd = ubi_open_volume
                    ubi_notify_remove
                     ubi_detach_mtd_dev
                      vfree(ubi->vtbl)
ioctl(fd, UBI_IOCVOLUP)
  ubi_start_update
   set_update_marker
    vtbl_rec = ubi->vtbl[vol->vol_id]  // UAF!

If we reserve ubi things even mtd driver is removed. There exists mtd 
drivers releasing mtd device (eg. phram_remove), then upper application 
could accessing released mtd device by the ubi device, which also 
triggers UAF in kernel.

After looking at nvme_free_ctrl, I found that nvme_dev is released when 
device refcnt becomes zero, so block device and nvme_dev won't be freed 
immediately when pci driver removed if upper filesystem being mounted on 
nvme device. And the mtd device's refcnt is held by ubi too, we may 
follow this method, but investigating all mtd drivers looks like 
unrealistic.

> @@ -546,7 +546,7 @@ static int ubiblock_notify(struct notifier_block *nb,
>   		 */
>   		break;
>   	case UBI_VOLUME_REMOVED:
> -		ubiblock_remove(&nt->vi);
> +		ubiblock_remove(&nt->vi, true);
>   		break;
>   	case UBI_VOLUME_RESIZED:
>   		ubiblock_resize(&nt->vi);
> diff --git a/drivers/mtd/ubi/cdev.c b/drivers/mtd/ubi/cdev.c
> index f43430b9c1e65..bb55e863dd296 100644
> --- a/drivers/mtd/ubi/cdev.c
> +++ b/drivers/mtd/ubi/cdev.c
> @@ -572,7 +572,7 @@ static long vol_cdev_ioctl(struct file *file, unsigned int cmd,
>   		struct ubi_volume_info vi;
>   
>   		ubi_get_volume_info(desc, &vi);
> -		err = ubiblock_remove(&vi);
> +		err = ubiblock_remove(&vi, false);
>   		break;
>   	}
>   
> diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
> index c8f1bd4fa1008..44c0eeaf1e1b0 100644
> --- a/drivers/mtd/ubi/ubi.h
> +++ b/drivers/mtd/ubi/ubi.h
> @@ -979,7 +979,7 @@ static inline void ubi_fastmap_destroy_checkmap(struct ubi_volume *vol) {}
>   int ubiblock_init(void);
>   void ubiblock_exit(void);
>   int ubiblock_create(struct ubi_volume_info *vi);
> -int ubiblock_remove(struct ubi_volume_info *vi);
> +int ubiblock_remove(struct ubi_volume_info *vi, bool force);
>   #else
>   static inline int ubiblock_init(void) { return 0; }
>   static inline void ubiblock_exit(void) {}
> @@ -987,7 +987,7 @@ static inline int ubiblock_create(struct ubi_volume_info *vi)
>   {
>   	return -ENOSYS;
>   }
> -static inline int ubiblock_remove(struct ubi_volume_info *vi)
> +static inline int ubiblock_remove(struct ubi_volume_info *vi, bool force)
>   {
>   	return -ENOSYS;
>   }
> 


  reply	other threads:[~2023-05-03 13:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-02 16:47 [PATCH 0/4] mtd: ubi: behave like a good MTD citizen Daniel Golle
2023-05-02 16:48 ` [PATCH 1/4] mtd: ubi: block: don't return on error when removing Daniel Golle
2023-05-03 13:09   ` Zhihao Cheng [this message]
2023-05-24  9:41     ` Daniel Golle
2023-05-26 10:15       ` Zhihao Cheng
2023-05-02 16:48 ` [PATCH 2/4] mtd: ubi: block: use notifier to create ubiblock from parameter Daniel Golle
2023-05-02 16:48 ` [PATCH 3/4] dt-bindings: mtd: partitions: add linux,ubi compatible Daniel Golle
2023-05-05 21:56   ` Rob Herring
2023-05-02 16:48 ` [PATCH 4/4] mtd: ubi: attach MTD partition from device-tree Daniel Golle

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=89f2a4a9-6054-80a8-285f-2be6c57c299d@huawei.com \
    --to=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=vigneshr@ti.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

all inboxes | Powered by JetHome®