From: David Hildenbrand <david@redhat.com>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Ruihan Li <lrh2000@pku.edu.cn>,
syzbot+fcf1a817ceb50935ce99@syzkaller.appspotmail.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: usbdev_mmap causes type confusion in page_table_check
Date: Tue, 9 May 2023 01:37:03 +0200 [thread overview]
Message-ID: <366ab078-1101-421c-691d-34f5efe006b5@redhat.com> (raw)
In-Reply-To: <CA+CK2bD=bv1vPGZaNcxDy-uUFj2ZAKkdPmAtJaweXhgTe91oEw@mail.gmail.com>
On 09.05.23 01:21, Pasha Tatashin wrote:
>> For normal Kernel-MM operations, vm_normal_page() should be used to
>> get "struct page" based on vma+addr+pte combination, but
>> page_table_check does not use vma for its operation in order to
>> strengthen the verification of no invalid page sharing. But, even
I'm not sure if that's the right approach for this case here, though.
>> vm_normal_page() can cause access to the "struct page" for VM_PFNMAP
>> if pfn_valid(pfn) is true. So, vm_normal_page() can return a struct
>> page for a user mapped slab page.
>
> Only for !ARCH_HAS_PTE_SPECIAL case, otherwise NULL is returned.
That would violate VM_PFNMAP semantics, though. I remember that there
was a trick to it.
Assuming we map /dev/mem, what stops a page we mapped and determined to
be !anon to be freed and reused, such that we suddenly have an anon page
mappped?
In that case, we really don't want to look at the "struct page" ever, no?
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2023-05-08 23:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-05 0:46 [syzbot] [mm?] kernel BUG in page_table_check_clear syzbot
2023-05-07 13:58 ` usbdev_mmap causes type confusion in page_table_check Ruihan Li
2023-05-08 21:27 ` Pasha Tatashin
2023-05-08 21:36 ` Matthew Wilcox
2023-05-08 21:48 ` Pasha Tatashin
2023-05-08 21:52 ` Matthew Wilcox
2023-05-08 21:55 ` Pasha Tatashin
2023-05-08 22:46 ` David Hildenbrand
2023-05-08 23:17 ` Pasha Tatashin
2023-05-08 23:21 ` Pasha Tatashin
2023-05-08 23:37 ` David Hildenbrand [this message]
2023-05-09 0:07 ` Pasha Tatashin
2023-05-08 21:37 ` David Hildenbrand
2023-05-09 13:25 ` Christoph Hellwig
2023-05-09 14:01 ` Greg KH
2023-05-10 13:17 ` Christoph Hellwig
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=366ab078-1101-421c-691d-34f5efe006b5@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-usb@vger.kernel.org \
--cc=lrh2000@pku.edu.cn \
--cc=pasha.tatashin@soleen.com \
--cc=syzbot+fcf1a817ceb50935ce99@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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