On Sat, Aug 22, 2026 at 08:14:02PM +0100, Lorenzo Stoakes (ARM) wrote: > secretmem has a relatively laissez-faire attitude to accounting the folios > it allocates. > > The intention is that the memory is treated as if it were mlock()'d and > thus is limited by the RLIMIT_MEMLOCK limit if the CAP_IPC_LOCK capability > is not in place (which broadly allows unlimited ranges of mlock()'d > memory). > > The lifecycle for memfd accounting against this limit is - account on map, > unaccount on unmap but the lifecycle of memfd folios is allocate on fault, > deallocate on inode eviction. > > This mismatch is problematic because the folios are unevictable and remain > so until the inode is evicted (set using mapping_set_unevictable()). > > This is problematic as it eliminates usual mlock() semantics - mapping > folios then unmapping them does not clear their unevictable state, since it > depends on AS_UNEVICTABLE, not PG_mlocked. > > A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply > map then unmap and VmLck no longer counts the secretmem range (or more > involved - fork which also achieves the same thing). > > Worse - they are not accounted in the process's RSS even if mapped again, > meaning the OOM killer won't know to kill the process. > > A user without the CAP_IPC_LOCK capability can therefore repeatedly > map/unmap (or map/fork) and consume all available system memory with > unevictable folios and cause system instability. > > A secretmem fd can be passed between processes and over fork so a > per-process limit simply does not make sense. > > So follow the precedent set by io_uring, perf, skbuff, iommufd and xdp - > track the number of locked pages in user_struct->locked_vm. > > Since the scope tracked is actually inode lifetime, the RLIMIT_MEMLOCK > applies per-user not per-process. Also given the change in scope it doesn't > make sense to bypass for users with CAP_IPC_LOCK, so remove it. > > There is simply no reason to carry on marking the mapping as mlock()'d > since it's misleading and the lifecycle is now correctly handled, so remove > this too. > > Additionally, fix the selftest which checks the limit as this now must > assert SIGBUS on limit violation on fault-in. > > __secretmem_account_pages() is more or less a duplicate of the code that > io_uring etc. use, but since this is a bug fix that needs backporting, > defer any de-duplication efforts to a follow-up. > > Reported-by: Daehyeon Ko <[email protected]> > Closes: > https://lore.kernel.org/linux-mm/[email protected]/ > Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create > "secret" memory areas") > Cc: [email protected] > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]>
Reviewed-by: Mike Rapoport (Microsoft) <[email protected]> -- Sincerely yours, Mike.
