lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260128121200.283932-1-clm@meta.com>
Date: Wed, 28 Jan 2026 04:08:36 -0800
From: Chris Mason <clm@...a.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
        Jarkko Sakkinen
	<jarkko@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas
 Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov
	<bp@...en8.de>, <x86@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>, Arnd
 Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Vishal Verma
	<vishal.l.verma@...el.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Maarten
 Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard
	<mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie
	<airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
        Jani Nikula
	<jani.nikula@...ux.intel.com>,
        Joonas Lahtinen
	<joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Tvrtko Ursulin <tursulin@...ulin.net>,
        Christian Koenig
	<christian.koenig@....com>,
        Huang Rui <ray.huang@....com>, Matthew Auld
	<matthew.auld@...el.com>,
        Matthew Brost <matthew.brost@...el.com>,
        Alexander
 Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan
 Kara <jack@...e.cz>,
        Benjamin LaHaise <bcrl@...ck.org>, Gao Xiang
	<xiang@...nel.org>,
        Chao Yu <chao@...nel.org>, Yue Hu <zbestahu@...il.com>,
        Jeffle Xu <jefflexu@...ux.alibaba.com>,
        Sandeep Dhavale <dhavale@...gle.com>,
        Hongbo Li <lihongbo22@...wei.com>, Chunhai Guo <guochunhai@...o.com>,
        Theodore Ts'o <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Muchun Song <muchun.song@...ux.dev>,
        Oscar Salvador <osalvador@...e.de>,
        David Hildenbrand <david@...nel.org>,
        Konstantin Komarov
	<almaz.alexandrovich@...agon-software.com>,
        Mike Marshall
	<hubcap@...ibond.com>,
        Martin Brandenburg <martin@...ibond.com>,
        Tony Luck
	<tony.luck@...el.com>,
        Reinette Chatre <reinette.chatre@...el.com>,
        Dave
 Martin <Dave.Martin@....com>, James Morse <james.morse@....com>,
        Babu Moger
	<babu.moger@....com>, Carlos Maiolino <cem@...nel.org>,
        Damien Le Moal
	<dlemoal@...nel.org>,
        Naohiro Aota <naohiro.aota@....com>,
        Johannes Thumshirn
	<jth@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        "Liam R . Howlett"
	<Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport
	<rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Michal Hocko
	<mhocko@...e.com>, Hugh Dickins <hughd@...gle.com>,
        Baolin Wang
	<baolin.wang@...ux.alibaba.com>, Zi Yan <ziy@...dia.com>,
        Nico Pache
	<npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
        Dev Jain
	<dev.jain@....com>, Barry Song <baohua@...nel.org>,
        Lance Yang
	<lance.yang@...ux.dev>, Jann Horn <jannh@...gle.com>,
        Pedro Falcato
	<pfalcato@...e.de>, David Howells <dhowells@...hat.com>,
        Paul Moore
	<paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
        "Serge E . Hallyn"
	<serge@...lyn.com>,
        Yury Norov <yury.norov@...il.com>,
        Rasmus Villemoes
	<linux@...musvillemoes.dk>,
        <linux-sgx@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <nvdimm@...ts.linux.dev>, <linux-cxl@...r.kernel.org>,
        <dri-devel@...ts.freedesktop.org>, <intel-gfx@...ts.freedesktop.org>,
        <linux-fsdevel@...r.kernel.org>, <linux-aio@...ck.org>,
        <linux-erofs@...ts.ozlabs.org>, <linux-ext4@...r.kernel.org>,
        <linux-mm@...ck.org>, <ntfs3@...ts.linux.dev>,
        <devel@...ts.orangefs.org>, <linux-xfs@...r.kernel.org>,
        <keyrings@...r.kernel.org>, <linux-security-module@...r.kernel.org>,
        Jason
 Gunthorpe <jgg@...dia.com>
Subject: Re: [PATCH v2 07/13] mm: update secretmem to use VMA flags on mmap_prepare

Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> This patch updates secretmem to use the new vma_flags_t type which will
> soon supersede vm_flags_t altogether.
> 
> In order to make this change we also have to update mlock_future_ok(), we
> replace the vm_flags_t parameter with a simple boolean is_vma_locked one,
> which also simplifies the invocation here.
> 
> This is laying the groundwork for eliminating the vm_flags_t in
> vm_area_desc and more broadly throughout the kernel.
> 

Hi everyone,

Running mm-new through AI review flagged this one:

> diff --git a/mm/mmap.c b/mm/mmap.c
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -225,12 +225,12 @@ static inline unsigned long round_hint_to_min(unsigned long hint)
>  	return hint;
>  }
>
> -bool mlock_future_ok(const struct mm_struct *mm, vm_flags_t vm_flags,
> -			unsigned long bytes)
> +bool mlock_future_ok(const struct mm_struct *mm, bool is_vma_locked,
> +		     unsigned long bytes)
>  {
>  	unsigned long locked_pages, limit_pages;
>
> -	if (!(vm_flags & VM_LOCKED) || capable(CAP_IPC_LOCK))
> +	if (!is_vma_locked || capable(CAP_IPC_LOCK))
>  		return true;

[ ... ]

> @@ -416,7 +416,7 @@
>  		if (!can_do_mlock())
>  			return -EPERM;
>
> -	if (!mlock_future_ok(mm, vm_flags, len))
> +	if (!mlock_future_ok(mm, vm_flags & VM_LOCKED, len))
>  		return -EAGAIN;

This looks correct - do_mmap() now extracts the VM_LOCKED bit from
vm_flags and passes that to mlock_future_ok().

However, it appears check_brk_limits() was not updated when
mlock_future_ok() changed its signature. The function at mm/mmap.c:111
still passes the raw def_flags value:

    return mlock_future_ok(current->mm, current->mm->def_flags, len)
        ? 0 : -EAGAIN;

When def_flags has any bit set, this converts to true, incorrectly
triggering mlock limit checks even when VM_LOCKED is not set. Should
this be passing (current->mm->def_flags & VM_LOCKED) instead?

[ ... ]

Additionally, the test stub at tools/testing/vma/vma_internal.h:1627
still has the old signature (mm, vm_flags_t vm_flags, bytes) while the
production code now uses (mm, bool is_vma_locked, bytes). This could
cause compilation issues or mask bugs in the test suite.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ