From: Al Viro <viro@zeniv.linux.org.uk>
To: Zhangfei Gao <zhangfei.gao@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Herbert Xu <herbert@gondor.apana.org.au>,
jean-philippe <jean-philippe@linaro.org>,
Wangzhou <wangzhou1@hisilicon.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
iommu@lists.linux.dev, acc@lists.linaro.org,
Weili Qian <qianweili@huawei.com>
Subject: Re: [PATCH] uacce: use filep->f_mapping to replace inode->i_mapping
Date: Thu, 11 May 2023 05:05:08 +0100 [thread overview]
Message-ID: <20230511040508.GF3390869@ZenIV> (raw)
In-Reply-To: <20230511021553.44318-1-zhangfei.gao@linaro.org>
On Thu, May 11, 2023 at 10:15:53AM +0800, Zhangfei Gao wrote:
> The inode can be different in a container, for example, a docker and host
> both open the same uacce parent device, which uses the same uacce struct
> but different inode, so uacce->inode is not enough.
>
> What's worse, when docker stops, the inode will be destroyed as well,
> causing use-after-free in uacce_remove.
>
> So use q->filep->f_mapping to replace uacce->inode->i_mapping.
> @@ -574,12 +574,6 @@ void uacce_remove(struct uacce_device *uacce)
>
> if (!uacce)
> return;
> - /*
> - * unmap remaining mapping from user space, preventing user still
> - * access the mmaped area while parent device is already removed
> - */
> - if (uacce->inode)
> - unmap_mapping_range(uacce->inode->i_mapping, 0, 0, 1);
>
> /*
> * uacce_fops_open() may be running concurrently, even after we remove
> @@ -589,6 +583,8 @@ void uacce_remove(struct uacce_device *uacce)
> mutex_lock(&uacce->mutex);
> /* ensure no open queue remains */
> list_for_each_entry_safe(q, next_q, &uacce->queues, list) {
> + struct file *filep = q->private_data;
> +
> /*
> * Taking q->mutex ensures that fops do not use the defunct
> * uacce->ops after the queue is disabled.
> @@ -597,6 +593,12 @@ void uacce_remove(struct uacce_device *uacce)
> uacce_put_queue(q);
> mutex_unlock(&q->mutex);
> uacce_unbind_queue(q);
> +
> + /*
> + * unmap remaining mapping from user space, preventing user still
> + * access the mmaped area while parent device is already removed
> + */
> + unmap_mapping_range(filep->f_mapping, 0, 0, 1);
IDGI. Going through uacce_queue instead of uacce_device is fine, but why
bother with file *or* inode? Just store a reference to struct address_space in
your uacce_queue and be done with that...
Another problem in that driver is uacce_vma_close(); this
if (vma->vm_pgoff < UACCE_MAX_REGION)
qfr = q->qfrs[vma->vm_pgoff];
kfree(qfr);
can't be right - you have q->qfrs left pointing to freed object. If nothing
else, subsequent mmap() will fail with -EEXIST, won't it?
next prev parent reply other threads:[~2023-05-11 4:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 2:15 [PATCH] uacce: use filep->f_mapping to replace inode->i_mapping Zhangfei Gao
2023-05-11 3:44 ` Greg Kroah-Hartman
2023-05-11 4:05 ` Al Viro [this message]
2023-05-11 9:56 ` Zhangfei Gao
2023-05-11 9:59 ` [PATCH v2 0/2] uacce misc fix Zhangfei Gao
2023-05-11 9:59 ` [PATCH v2 1/2] uacce: use q->mapping to replace inode->i_mapping Zhangfei Gao
2023-05-11 9:59 ` [PATCH v2 2/2] uacce: vma_close clears q->qfrs when freeing qfrs Zhangfei Gao
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=20230511040508.GF3390869@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=Jonathan.Cameron@huawei.com \
--cc=acc@lists.linaro.org \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qianweili@huawei.com \
--cc=wangzhou1@hisilicon.com \
--cc=zhangfei.gao@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox