From: Miklos Szeredi <miklos@szeredi.hu>
To: David Hildenbrand <david@redhat.com>
Cc: xingwei lee <xrivendell7@gmail.com>,
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: Mon, 25 Mar 2024 12:21:04 +0100 [thread overview]
Message-ID: <CAJfpegtssacBQuV0J2cEFYOJQvg-p10thsMEq2W87SEonqLnkg@mail.gmail.com> (raw)
In-Reply-To: <b40eb0b7-7362-4d19-95b3-e06435e6e09c@redhat.com>
On Fri, 22 Mar 2024 at 22:56, David Hildenbrand <david@redhat.com> wrote:
> From 85558a46d9f249f26bd77dd3b18d14f248464845 Mon Sep 17 00:00:00 2001
> From: David Hildenbrand <david@redhat.com>
> Date: Fri, 22 Mar 2024 22:45:36 +0100
> Subject: [PATCH] mm/secretmem: fix GUP-fast succeeding on secretmem folios
>
> folio_is_secretmem() states that secretmem folios cannot be LRU folios:
> so we may only exit early if we find an LRU folio. Yet, we exit early if
> we find a folio that is not a secretmem folio.
>
> Consequently, folio_is_secretmem() fails to detect secretmem folios and,
> therefore, we can succeed in grabbing a secretmem folio during GUP-fast,
> crashing the kernel when we later try reading/writing to the folio, because
> the folio has been unmapped from the directmap.
>
> Reported-by: xingwei lee <xrivendell7@gmail.com>
> Reported-by: yue sun <samsun1006219@gmail.com>
> Debugged-by: Miklos Szeredi <miklos@szeredi.hu>
> Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Verified that it's no longer crashing with the reproducers.
Tested-by: Miklos Szeredi <mszeredi@redhat.com>
prev parent reply other threads:[~2024-03-25 11:21 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
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 [this message]
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=CAJfpegtssacBQuV0J2cEFYOJQvg-p10thsMEq2W87SEonqLnkg@mail.gmail.com \
--to=miklos@szeredi.hu \
--cc=david@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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.