From: Jens Axboe <axboe@kernel.dk>
To: Zhong Jinghua <zhongjinghua@huaweicloud.com>, josef@toxicpanda.com
Cc: linux-block@vger.kernel.org, nbd@other.debian.org,
linux-kernel@vger.kernel.org, yi.zhang@huawei.com,
yukuai3@huawei.com
Subject: Re: [PATCH -next] nbd: get config_lock before sock_shutdown
Date: Mon, 31 Jul 2023 18:27:57 -0600 [thread overview]
Message-ID: <1b67a9dd-c28a-661a-3a46-dab509d4c34e@kernel.dk> (raw)
In-Reply-To: <20230707062256.1271948-1-zhongjinghua@huaweicloud.com>
On 7/7/23 12:22?AM, Zhong Jinghua wrote:
> Config->socks in sock_shutdown may trigger a UAF problem.
> The reason is that sock_shutdown does not hold the config_lock,
> so that nbd_ioctl can release config->socks at this time.
>
> T0: NBD_SET_SOCK
> T1: NBD_DO_IT
>
> T0 T1
>
> nbd_ioctl
> mutex_lock(&nbd->config_lock)
> // get lock
> __nbd_ioctl
> nbd_start_device_ioctl
> nbd_start_device
> mutex_unlock(&nbd->config_lock)
> // relase lock
> wait_event_interruptible
> (kill, enter sock_shutdown)
> sock_shutdown
> nbd_ioctl
> mutex_lock(&nbd->config_lock)
> // get lock
> __nbd_ioctl
> nbd_add_socket
> krealloc
> kfree(p)
> //config->socks is NULL
> nbd_sock *nsock = config->socks // error
>
> Fix it by moving config_lock up before sock_shutdown.
>
> Signed-off-by: Zhong Jinghua <zhongjinghua@huaweicloud.com>
> ---
> drivers/block/nbd.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index c410cf29fb0c..accbe99ebb7e 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -1428,13 +1428,18 @@ static int nbd_start_device_ioctl(struct nbd_device *nbd)
> mutex_unlock(&nbd->config_lock);
> ret = wait_event_interruptible(config->recv_wq,
> atomic_read(&config->recv_threads) == 0);
> +
> + /*
> + * recv_work in flush_workqueue will not get this lock, because nbd_open
> + * will hold nbd->config_refs
> + */
> + mutex_lock(&nbd->config_lock);
> if (ret) {
> sock_shutdown(nbd);
> nbd_clear_que(nbd);
> }
>
> flush_workqueue(nbd->recv_workq);
> - mutex_lock(&nbd->config_lock);
Feels pretty iffy to hold config_lock over the flush. If anything off
recv_work() ever grabs it, we'd be stuck. Your comment assumes that the
only case this will currently happen is if we drop the last ref, or at
least that's the case that'd do it even if you don't mention it
explicitly.
Maybe this is all fine, but recv_work() should have a comment matching
this one, and this comment should be more descriptive as well.
--
Jens Axboe
next prev parent reply other threads:[~2023-08-01 0:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-07 6:22 Zhong Jinghua
2023-07-28 7:10 ` Yu Kuai
2023-08-01 0:27 ` Jens Axboe [this message]
2023-09-28 6:04 ` Yu Kuai
2023-10-30 8:49 ` zhongjinghua
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=1b67a9dd-c28a-661a-3a46-dab509d4c34e@kernel.dk \
--to=axboe@kernel.dk \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nbd@other.debian.org \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.com \
--cc=zhongjinghua@huaweicloud.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®