From: Ruihan Li <lrh2000@pku.edu.cn>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-mm@kvack.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org,
Pasha Tatashin <pasha.tatashin@soleen.com>,
David Hildenbrand <david@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Ruihan Li <lrh2000@pku.edu.cn>
Subject: Re: [PATCH 0/4] Fix type confusion in page_table_check
Date: Thu, 11 May 2023 21:44:55 +0800 [thread overview]
Message-ID: <cyym2uqyqdtegfbdpworng4fa7iiuyh3e2wjrf4lp47jksvoxt@wwhvnzy5757c> (raw)
In-Reply-To: <2023051108-lens-unsocial-8425@gregkh>
On Thu, May 11, 2023 at 07:51:58AM +0900, Greg Kroah-Hartman wrote:
> On Wed, May 10, 2023 at 04:55:23PM +0800, Ruihan Li wrote:
> > Recently, syzbot reported [1] ("kernel BUG in page_table_check_clear").
> > The root cause is that usbdev_mmap calls remap_pfn_range on kmalloc'ed
> > memory, which leads to type confusion between struct page and slab in
> > page_table_check. This series of patches fixes the usb side by avoiding
> > mapping slab pages into userspace, and fixes the mm side by enforcing
> > that all user-accessible pages are not slab pages. A more detailed
> > analysis and some discussion of how to fix the problem can also be found
> > in [1].
> >
> > [1] https://lore.kernel.org/lkml/20230507135844.1231056-1-lrh2000@pku.edu.cn/T/
>
> Can you see if you can implement Christoph's proposed change instead:
> https://lore.kernel.org/r/ZFuZVDcU81WmqEvJ@infradead.org
>
> As it might not actually be as bad as you think to require this type of
> churn.
>
> thanks,
>
> greg k-h
Sorry, but no.
Christoph's patch perfectly fixes _one_ problem: kmalloc'ed memory
cannot be mapped to user space. However, as I detailed in the commit
message, this series of patches fixes _three_ problems.
I have to say that the original code is quite buggy. In the
gen_pool_dma_alloc path, there is no guarantee of page alignment.
void *hcd_buffer_alloc(...)
{
// ...
if (hcd->localmem_pool)
return gen_pool_dma_alloc(hcd->localmem_pool, size, dma);
// ...
}
When localmem_pool gets initialized, the alignment bits are set to 4
(instead of PAGE_SHIFT).
int usb_hcd_setup_local_mem(struct usb_hcd *hcd, phys_addr_t phys_addr,
dma_addr_t dma, size_t size)
{
// ...
hcd->localmem_pool = devm_gen_pool_create(hcd->self.sysdev, 4,
dev_to_node(hcd->self.sysdev),
dev_name(hcd->self.sysdev));
// ...
}
It is introduced by commit ff2437befd8f ("usb: host: Fix excessive
alignment restriction for local memory allocations") [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff2437befd8fe52046e0db949347b5bcfab6b097
If you don't believe me, please see my test results. In the following
qemu setup,
qemu-system-sh4 -M r2d -kernel arch/sh/boot/zImage \
-usb -device usb-storage,drive=d0 \
-drive file=test.img,if=none,id=d0,format=raw \
-append "console=tty0 console=ttySC1,115200 rootwait root=/dev/sda init=/bin/sh" \
-serial null -serial stdio
together with the following patch,
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index e501a03d6..d7069c986 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -265,6 +265,10 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
INIT_LIST_HEAD(&usbm->memlist);
if (hcd->localmem_pool || !hcd_uses_dma(hcd)) {
+ printk("usb_alloc_coherent returns %px\n", usbm->mem);
+ printk("so the mapping starts at %lx\n",
+ virt_to_phys(usbm->mem) >> PAGE_SHIFT);
+
if (remap_pfn_range(vma, vma->vm_start,
virt_to_phys(usbm->mem) >> PAGE_SHIFT,
size, vma->vm_page_prot) < 0) {
it quickly leads to the following output when I manage to map a page
from /dev/bus/usb/001/002,
usb_alloc_coherent returns b07c06c0
so the mapping starts at 307c0
What's more, in this case, remap_pfn_range should _not_ be used, since
we are going to map a DMA page. However, as you can see, usbdev_mmap
actually goes to the wrong path.
If you say I shouldn't fix all these bugs in _this_ patch series, that's
fine. However, I do think that these bugs should be fixed, perhaps in
another patch series.
Thanks,
Ruihan Li
next prev parent reply other threads:[~2023-05-11 13:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 8:55 Ruihan Li
2023-05-10 8:55 ` [PATCH 1/4] usb: usbfs: Enforce page requirements for mmap Ruihan Li
2023-05-10 14:37 ` Alan Stern
2023-05-10 15:38 ` Ruihan Li
2023-05-10 8:55 ` [PATCH 2/4] usb: usbfs: Use consistent mmap functions Ruihan Li
2023-05-10 14:38 ` Alan Stern
2023-05-10 15:41 ` Ruihan Li
2023-05-10 16:34 ` David Hildenbrand
2023-05-10 8:55 ` [PATCH 3/4] mm: page_table_check: Make it dependent on !DEVMEM Ruihan Li
2023-05-10 16:40 ` David Hildenbrand
2023-05-11 16:07 ` Ruihan Li
2023-05-10 8:55 ` [PATCH 4/4] mm: page_table_check: Ensure user pages are not slab pages Ruihan Li
2023-05-10 22:51 ` [PATCH 0/4] Fix type confusion in page_table_check Greg Kroah-Hartman
2023-05-11 13:44 ` Ruihan Li [this message]
2023-05-11 15:32 ` Christoph Hellwig
[not found] ` <zwixiok55avpjvfiknp7tzm7e4aragjj43a46abna4qqegdvdx@suat6sk34lgb>
2023-05-13 9:37 ` Greg Kroah-Hartman
2023-05-14 15:08 ` Ruihan Li
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=cyym2uqyqdtegfbdpworng4fa7iiuyh3e2wjrf4lp47jksvoxt@wwhvnzy5757c \
--to=lrh2000@pku.edu.cn \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-usb@vger.kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=willy@infradead.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