From: Mike Rapoport <rppt@kernel.org>
To: n3rd <18670333770@163.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
peterx@redhat.com, ljs@kernel.org, akpm@linux-foundation.org,
security@kernel.org
Subject: Re: [SECURITY] mm: mremap() merge silently disarms a userfaultfd VMA
Date: Tue, 10 Nov 2026 11:03:10 +0200 [thread overview]
Message-ID: <avLdzhUz2uUIEGkR@kernel.org> (raw)
In-Reply-To: <10acf436.5b2b.1a1c45e0bb8.Coremail.18670333770@163.com>
Hi,
On Tue, Nov 10, 2026 at 03:31:00PM +0800, n3rd wrote:
> Hello,
> I am reporting a security bug in the Linux kernel.
> 1. Affected kernel versions
> Linux v7.3-rc7 (mainline, built and tested as 7.3.0-rc7 with KASAN) is
> affected and the issue was reproduced in two fresh QEMU boots plus a
> control boot on it.
...
> 6. Suggested fix
> mremap_userfaultfd_prep() must only drop the context of the range that
> was actually copied, not of a pre-existing VMA that absorbed it. Either
> have copy_vma() report whether it merged into a neighbour and, in that
> case, restrict or skip the reset, or refuse the merge in
> vma_merge_copied_range() when the neighbour is uffd-armed and the
> caller does not have UFFD_FEATURE_EVENT_REMAP. No upstream patch exists
> as of v7.3-rc7 and no patch is included in this report; one can be
> provided on request.
This was already reported [1] and fixed by commit 68cb098eadda ("mm/vma:
avoid broken uffd merge on mremap") that is in v7.4-rc1 and is tagged
for stable.
[1] https://lore.kernel.org/all/20261020110748.959870-1-shawnq1@163.com/
Please check the latest upstream before sending reports.
--
Sincerely yours,
Mike.
prev parent reply other threads:[~2026-11-10 9:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 7:31 [SECURITY] mm: mremap() merge silently disarms a userfaultfd VMA n3rd
2026-11-10 9:03 ` Mike Rapoport [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=avLdzhUz2uUIEGkR@kernel.org \
--to=rppt@kernel.org \
--cc=18670333770@163.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=peterx@redhat.com \
--cc=security@kernel.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 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.