From: David Hildenbrand <david@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>, xingwei lee <xrivendell7@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
samsun1006219@gmail.com, syzkaller-bugs@googlegroups.com,
linux-mm <linux-mm@kvack.org>, Mike Rapoport <rppt@kernel.org>
Subject: Re: BUG: unable to handle kernel paging request in fuse_copy_do
Date: Fri, 22 Mar 2024 16:41:17 +0100 [thread overview]
Message-ID: <c58a8dc8-5346-4247-9a0a-8b1be286e779@redhat.com> (raw)
In-Reply-To: <CAJfpegu8qTARQBftZSaiif0E6dbRcbBvZvW7dQf8sf_ymoogCA@mail.gmail.com>
On 22.03.24 14:50, Miklos Szeredi wrote:
> [MM list + secretmem author CC-d]
>
> On Thu, 21 Mar 2024 at 08:52, xingwei lee <xrivendell7@gmail.com> wrote:
>>
>> Hello I found a bug titled "BUG: unable to handle kernel paging
>> request in fuse_copy_do” with modified syzkaller, and maybe it is
>> related to fs/fuse.
>> I also confirmed in the latest upstream.
>>
>> If you fix this issue, please add the following tag to the commit:
>> Reported-by: xingwei lee <xrivendell7@gmail.com>
>> Reported-by: yue sun <samsun1006219@gmail.com>
>
> Thanks for the report. This looks like a secretmem vs get_user_pages issue.
>
> I reduced the syz reproducer to a minimal one that isn't dependent on fuse:
>
> === repro.c ===
> #define _GNU_SOURCE
>
> #include <fcntl.h>
> #include <unistd.h>
> #include <sys/mman.h>
> #include <sys/syscall.h>
> #include <sys/socket.h>
>
> int main(void)
> {
> int fd1, fd2, fd3;
> int pip[2];
> struct iovec iov;
> void *addr;
>
> fd1 = syscall(__NR_memfd_secret, 0);
> addr = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd1, 0);
> ftruncate(fd1, 7);
> fd2 = socket(AF_INET, SOCK_DGRAM, 0);
> getsockopt(fd2, 0, 0, NULL, addr);
>
> pipe(pip);
> iov.iov_base = addr;
> iov.iov_len = 0x50;
> vmsplice(pip[1], &iov, 1, 0);
pip[1] should be the write end. So it will be used as the source.
I assume we go the ITER_SOURCE path in vmsplice, and call
vmsplice_to_pipe(). Then we call iter_to_pipe().
I would expect iov_iter_get_pages2() -> get_user_pages_fast() to fail on
secretmem pages?
But at least the vmsplice() just seems to work. Which is weird, because
GUP-fast should not apply (page not faulted in?) and check_vma_flags()
bails out early on vma_is_secretmem(vma).
So something is not quite right.
>
> fd3 = open("/tmp/repro-secretmem.test", O_RDWR | O_CREAT, 0x600);
> splice(pip[0], NULL, fd3, NULL, 0x50, 0);
>
> return 0;
> }
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-03-22 15:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-21 7:52 BUG: unable to handle kernel paging request in fuse_copy_do xingwei lee
2024-03-22 13:50 ` Miklos Szeredi
2024-03-22 15:41 ` David Hildenbrand [this message]
2024-03-22 19:46 ` Miklos Szeredi
2024-03-22 21:08 ` David Hildenbrand
2024-03-22 21:13 ` Miklos Szeredi
2024-03-22 21:18 ` David Hildenbrand
2024-03-22 21:33 ` David Hildenbrand
2024-03-22 21:37 ` David Hildenbrand
2024-03-22 21:56 ` David Hildenbrand
2024-03-24 10:29 ` Mike Rapoport
2024-03-25 11:21 ` Miklos Szeredi
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=c58a8dc8-5346-4247-9a0a-8b1be286e779@redhat.com \
--to=david@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=miklos@szeredi.hu \
--cc=rppt@kernel.org \
--cc=samsun1006219@gmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=xrivendell7@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.