From: Yu Kuai <yukuai1@huaweicloud.com>
To: stable@vger.kernel.org, stable-commits@vger.kernel.org, xni@redhat.com
Cc: Song Liu <song@kernel.org>, "yukuai (C)" <yukuai3@huawei.com>
Subject: Re: Patch "md: call del_gendisk in control path" has been added to the 6.6-stable tree
Date: Mon, 18 Aug 2025 09:03:39 +0800 [thread overview]
Message-ID: <7748b907-8279-c222-d4e4-b94c3216408b@huaweicloud.com> (raw)
In-Reply-To: <20250817141818.2370452-1-sashal@kernel.org>
Hi,
在 2025/08/17 22:18, Sasha Levin 写道:
> This is a note to let you know that I've just added the patch titled
>
> md: call del_gendisk in control path
>
> to the 6.6-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
> The filename of the patch is:
> md-call-del_gendisk-in-control-path.patch
> and it can be found in the queue-6.6 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
>
>
This patch should be be backported to any stable kernel, this change
will break user tools mdadm:
https://lore.kernel.org/all/f654db67-a5a5-114b-09b8-00db303daab7@redhat.com/
Thanks,
Kuai
>
> commit fa738623105e2dd4865274dc8525856feaec3ae9
> Author: Xiao Ni <xni@redhat.com>
> Date: Wed Jun 11 15:31:06 2025 +0800
>
> md: call del_gendisk in control path
>
> [ Upstream commit 9e59d609763f70a992a8f3808dabcce60f14eb5c ]
>
> Now del_gendisk and put_disk are called asynchronously in workqueue work.
> The asynchronous way has a problem that the device node can still exist
> after mdadm --stop command returns in a short window. So udev rule can
> open this device node and create the struct mddev in kernel again. So put
> del_gendisk in control path and still leave put_disk in md_kobj_release
> to avoid uaf of gendisk.
>
> Function del_gendisk can't be called with reconfig_mutex. If it's called
> with reconfig mutex, a deadlock can happen. del_gendisk waits all sysfs
> files access to finish and sysfs file access waits reconfig mutex. So
> put del_gendisk after releasing reconfig mutex.
>
> But there is still a window that sysfs can be accessed between mddev_unlock
> and del_gendisk. So some actions (add disk, change level, .e.g) can happen
> which lead unexpected results. MD_DELETED is used to resolve this problem.
> MD_DELETED is set before releasing reconfig mutex and it should be checked
> for these sysfs access which need reconfig mutex. For sysfs access which
> don't need reconfig mutex, del_gendisk will wait them to finish.
>
> But it doesn't need to do this in function mddev_lock_nointr. There are
> ten places that call it.
> * Five of them are in dm raid which we don't need to care. MD_DELETED is
> only used for md raid.
> * stop_sync_thread, md_do_sync and md_start_sync are related sync request,
> and it needs to wait sync thread to finish before stopping an array.
> * md_ioctl: md_open is called before md_ioctl, so ->openers is added. It
> will fail to stop the array. So it doesn't need to check MD_DELETED here
> * md_set_readonly:
> It needs to call mddev_set_closing_and_sync_blockdev when setting readonly
> or read_auto. So it will fail to stop the array too because MD_CLOSING is
> already set.
>
> Reviewed-by: Yu Kuai <yukuai3@huawei.com>
> Signed-off-by: Xiao Ni <xni@redhat.com>
> Link: https://lore.kernel.org/linux-raid/20250611073108.25463-2-xni@redhat.com
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index b086cbf24086..8e3939c0d2ed 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -639,9 +639,6 @@ static void __mddev_put(struct mddev *mddev)
> mddev->ctime || mddev->hold_active)
> return;
>
> - /* Array is not configured at all, and not held active, so destroy it */
> - set_bit(MD_DELETED, &mddev->flags);
> -
> /*
> * Call queue_work inside the spinlock so that flush_workqueue() after
> * mddev_find will succeed in waiting for the work to be done.
> @@ -837,6 +834,16 @@ void mddev_unlock(struct mddev *mddev)
> kobject_del(&rdev->kobj);
> export_rdev(rdev, mddev);
> }
> +
> + /* Call del_gendisk after release reconfig_mutex to avoid
> + * deadlock (e.g. call del_gendisk under the lock and an
> + * access to sysfs files waits the lock)
> + * And MD_DELETED is only used for md raid which is set in
> + * do_md_stop. dm raid only uses md_stop to stop. So dm raid
> + * doesn't need to check MD_DELETED when getting reconfig lock
> + */
> + if (test_bit(MD_DELETED, &mddev->flags))
> + del_gendisk(mddev->gendisk);
> }
> EXPORT_SYMBOL_GPL(mddev_unlock);
>
> @@ -5616,19 +5623,30 @@ md_attr_store(struct kobject *kobj, struct attribute *attr,
> struct md_sysfs_entry *entry = container_of(attr, struct md_sysfs_entry, attr);
> struct mddev *mddev = container_of(kobj, struct mddev, kobj);
> ssize_t rv;
> + struct kernfs_node *kn = NULL;
>
> if (!entry->store)
> return -EIO;
> if (!capable(CAP_SYS_ADMIN))
> return -EACCES;
> +
> + if (entry->store == array_state_store && cmd_match(page, "clear"))
> + kn = sysfs_break_active_protection(kobj, attr);
> +
> spin_lock(&all_mddevs_lock);
> if (!mddev_get(mddev)) {
> spin_unlock(&all_mddevs_lock);
> + if (kn)
> + sysfs_unbreak_active_protection(kn);
> return -EBUSY;
> }
> spin_unlock(&all_mddevs_lock);
> rv = entry->store(mddev, page, length);
> mddev_put(mddev);
> +
> + if (kn)
> + sysfs_unbreak_active_protection(kn);
> +
> return rv;
> }
>
> @@ -5636,12 +5654,6 @@ static void md_kobj_release(struct kobject *ko)
> {
> struct mddev *mddev = container_of(ko, struct mddev, kobj);
>
> - if (mddev->sysfs_state)
> - sysfs_put(mddev->sysfs_state);
> - if (mddev->sysfs_level)
> - sysfs_put(mddev->sysfs_level);
> -
> - del_gendisk(mddev->gendisk);
> put_disk(mddev->gendisk);
> }
>
> @@ -6531,8 +6543,9 @@ static int do_md_stop(struct mddev *mddev, int mode,
> mddev->bitmap_info.offset = 0;
>
> export_array(mddev);
> -
> md_clean(mddev);
> + set_bit(MD_DELETED, &mddev->flags);
> +
> if (mddev->hold_active == UNTIL_STOP)
> mddev->hold_active = 0;
> }
> diff --git a/drivers/md/md.h b/drivers/md/md.h
> index 46995558d3bd..0a7c9122db50 100644
> --- a/drivers/md/md.h
> +++ b/drivers/md/md.h
> @@ -589,11 +589,26 @@ static inline bool is_md_suspended(struct mddev *mddev)
>
> static inline int __must_check mddev_lock(struct mddev *mddev)
> {
> - return mutex_lock_interruptible(&mddev->reconfig_mutex);
> + int ret;
> +
> + ret = mutex_lock_interruptible(&mddev->reconfig_mutex);
> +
> + /* MD_DELETED is set in do_md_stop with reconfig_mutex.
> + * So check it here.
> + */
> + if (!ret && test_bit(MD_DELETED, &mddev->flags)) {
> + ret = -ENODEV;
> + mutex_unlock(&mddev->reconfig_mutex);
> + }
> +
> + return ret;
> }
>
> /* Sometimes we need to take the lock in a situation where
> * failure due to interrupts is not acceptable.
> + * It doesn't need to check MD_DELETED here, the owner which
> + * holds the lock here can't be stopped. And all paths can't
> + * call this function after do_md_stop.
> */
> static inline void mddev_lock_nointr(struct mddev *mddev)
> {
> @@ -602,7 +617,14 @@ static inline void mddev_lock_nointr(struct mddev *mddev)
>
> static inline int mddev_trylock(struct mddev *mddev)
> {
> - return mutex_trylock(&mddev->reconfig_mutex);
> + int ret;
> +
> + ret = mutex_trylock(&mddev->reconfig_mutex);
> + if (!ret && test_bit(MD_DELETED, &mddev->flags)) {
> + ret = -ENODEV;
> + mutex_unlock(&mddev->reconfig_mutex);
> + }
> + return ret;
> }
> extern void mddev_unlock(struct mddev *mddev);
>
> .
>
next parent reply other threads:[~2025-08-18 1:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250817141818.2370452-1-sashal@kernel.org>
2025-08-18 1:03 ` Yu Kuai [this message]
2025-08-18 5:55 ` Patch "md: call del_gendisk in control path" has been added to the 6.6-stable tree Greg KH
2025-08-18 6:26 ` Yu Kuai
2025-08-18 6:38 ` Greg KH
2025-08-18 7:13 ` Yu Kuai
2025-08-18 9:39 ` Greg KH
2025-08-19 1:06 ` Yu Kuai
2025-08-19 6:12 ` Greg KH
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=7748b907-8279-c222-d4e4-b94c3216408b@huaweicloud.com \
--to=yukuai1@huaweicloud.com \
--cc=song@kernel.org \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=xni@redhat.com \
--cc=yukuai3@huawei.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;
as well as URLs for NNTP newsgroup(s).