linux-kernel - Re: [PATCH v5 10/11] lsm: consolidate all of the LSM framework initcalls

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: <14638978-b133-457a-ae9c-31ba54e3964c@lucifer.local>
Date: Thu, 29 Jan 2026 16:48:07 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Paul Moore <paul@...l-moore.com>
Cc: linux-security-module@...r.kernel.org, linux-integrity@...r.kernel.org,
        selinux@...r.kernel.org, john.johansen@...onical.com,
        zohar@...ux.ibm.com, roberto.sassu@...wei.com, wufan@...nel.org,
        mic@...ikod.net, gnoack@...gle.com, kees@...nel.org,
        mortonm@...omium.org, casey@...aufler-ca.com,
        penguin-kernel@...ove.sakura.ne.jp,
        nicolas.bouchinet@....cyber.gouv.fr, xiujianfeng@...wei.com,
        linux-mm <linux-mm@...ck.org>, David Hildenbrand <david@...hat.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 10/11] lsm: consolidate all of the LSM framework
 initcalls

On Thu, Jan 29, 2026 at 04:31:16PM +0000, Lorenzo Stoakes wrote:
> +cc linux-mm, maintainers/reviewers of mm/Kconfig
>
> On Fri, Oct 17, 2025 at 04:48:24PM -0400, Paul Moore wrote:
> > The LSM framework itself registers a small number of initcalls, this
> > patch converts these initcalls into the new initcall mechanism.
> >
> > Reviewed-by: Casey Schaufler <casey@...aufler-ca.com>
> > Reviewed-by: John Johansen <john.johhansen@...onical.com>
> > Signed-off-by: Paul Moore <paul@...l-moore.com>
>
> Hi,
>
> This commit message doesn't mention at all that you've removed
> /proc/sys/vm/mmap_min_addr altogether if CONFIG_SECURITY is not set.
>
> Did you intend this change? If you did you should probably mention that
> you're doing this :)
>
> I mean it's a bit late now as this is upstream (but not _too_ late as we
> have rc8 ;), but this has broken something for me locally (mremap mm
> selftest) and I bisected to this commit.
>
> Note that CONFIG_SECURITY states:
>
> 	  This allows you to choose different security modules to be
> 	  configured into your kernel.
>
> 	  If this option is not selected, the default Linux security
> 	  model will be used.
>
> So is the 'default' Linux security model not to provide this tunable at
> all?
>
> Though I see LSM_MMAP_MIN_ADDR depends on SECURITY && SECURITY_SELINUX, the
> Makefile in security/ has:
>
> obj-$(CONFIG_MMU)			+= min_addr.o
>
> Which suggests that min_addr depends on MMU only, and not on
> LSM_MMAP_MIN_ADDR at all...
>
> And I don't have CONFIG_SECURITY_SELINUX set yet have
> /proc/sys/vm/mmap_min_addr?

Sorry to clarify here I meant to say - if I set CONFIG_SECURITY but _not_
CONFIG_SECURITY_SELINUX the tunable does in fact still appear (and afaict
still work...)

So LSM_MMAP_MIN_ADDR is really weird to require SECURITY_SELINUX, perhaps a
historic artifact where we wanted a different default or something like
this?

I know that we use that in preference to CONFIG_DEFAULT_MMAP_MIN_ADDR if
specified.

The description really probably needs updating.

The key config here we should be looking at is DEFAULT_MMAP_MIN_ADDR which
emphatically does _not_ require CONFIG_SECURITY and also in its description
explicitly mentions the tunable:

	  This value can be changed after boot using the
	  /proc/sys/vm/mmap_min_addr tunable.

The mmap_min_addr global value exposed in min_addr.c is referenced in
several places in mm and other parts of the kernel - fs/exec.c,
fs/userlandfd.c, kernel/sys.c, mm/mmap.c, mm/vma.c.

So this now silently going to zero everywhere and ignoring
CONFIG_DEFAULT_MMAP_MIN_ADDR is surely a userspace-breaking regression and
needs fixing in rc8?

Which means that... people can now mmap() at NULL everywhere despite setting
CONFIG_DEFAULT_MMAP_MIN_ADDR > 0? :)

That seems like a _really bad idea_ (TM).

So this is emphatically not a report of a trivial self test break, but
rather of something more serious AFAICT.

So yeah I think this has to be reverted/fixed.

Thanks, Lorenzo