From: Andrew Morton <akpm@linux-foundation.org>
To: Daehyeon Ko <4ncienth@gmail.com>
Cc: Mike Rapoport <rppt@kernel.org>,
linux-mm@kvack.org, David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R . Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/secretmem: prevent uncharged mremap expansion after fork
Date: Mon, 17 Aug 2026 15:43:56 -0700 [thread overview]
Message-ID: <20260817154356.552ccde5d279f6e0a9ef0ff2@linux-foundation.org> (raw)
In-Reply-To: <20260813225328.2010303-1-4ncienth@gmail.com>
On Fri, 14 Aug 2026 07:53:28 +0900 Daehyeon Ko <4ncienth@gmail.com> wrote:
> Secretmem mappings are charged against RLIMIT_MEMLOCK and marked
> VM_LOCKED because their pages are unevictable and removed from the direct
> map.
>
> dup_mmap() clears VM_LOCKED on the child copy, but mremap() uses that
> flag to decide whether an expansion needs a memlock limit check and
> accounting. An unprivileged child can therefore expand an inherited
> secretmem VMA past its limit and populate the added range.
>
> Add a VMA open callback that marks secretmem copies without VM_LOCKED as
> VM_DONTEXPAND. dup_mmap() invokes the callback after clearing VM_LOCKED,
> while the original charged mapping retains its existing ability to grow
> within the limit.
Thanks.
> Add a selftest that verifies expansion of an inherited secretmem VMA is
> rejected.
And that's a nice touch.
> Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas")
> Cc: stable@vger.kernel.org
AI review might have found what appears to be a related bug in there:
https://sashiko.dev/#/patchset/20260813225328.2010303-1-4ncienth@gmail.com
Do you think that's pertinent to your fix, or should it be addressed
separately?
next prev parent reply other threads:[~2026-08-17 22:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 22:53 [PATCH] mm/secretmem: prevent uncharged mremap expansion after fork Daehyeon Ko
2026-08-14 8:21 ` Lorenzo Stoakes (ARM)
2026-08-17 22:43 ` Andrew Morton [this message]
2026-08-18 3:42 ` Daehyeon Ko
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=20260817154356.552ccde5d279f6e0a9ef0ff2@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=4ncienth@gmail.com \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@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.