Skip to contentSkip to conversation

mm: call the security_mmap_file() LSM hook in remap_file_pages()

DISCUSSION Applied gregkh 3 participants 7 messages Oct 27 – Oct 28 1 message not in the archive Stable branch

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

gregkh

author maintainer
#1 lore raw
Quoted 14 lines · On Tue, Oct 27, 2026 at 11:37:21AM +0800, [email protected] wrote:

Dear 5.15.y maintainers,

An mm patch should be backported from upstream mainline to the stable 5.15.y branch. The patch's information is shown as below:

[Subject]
mm: call the security_mmap_file() LSM hook in remap_file_pages()

[Upstream commit ID]
0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1

[Kernel version]
5.15.y

Quoted 10 lines

[Why]
The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux.
So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux.

Please provide a working backport that you have tested for this, as it does not apply cleanly on its own.

Also note that 5.15.y will only be alive for one more month, so why aren't you moving off of this kernel version already instead of wanting to add a new bugfix to it when there are already 2000+ unfixed CVEs in that tree?

thanks,

greg k-h

#2 lore raw

Hi gregkh

I have verified the following:

1. The patch can be applied to the linux-5.15.y branch. The commit applies cleanly on top of v5.15.223 (using git cherry-pick -x, with no conflicts):

git cherry-pick -x 0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1 with no conflicts

git log --oneline
it can view the commit history.

2. Our customer is using the 5.15.y branch The customer has requested the inclusion of these CVEs. and is unwilling to upgrade to version 6.x or higher.

Furthermore, as they are using GKI 2.0, they cannot apply "autopatch." the only way to incorporate fixes for CVEs is by updating the LTS.

-------------------------------------
From: gregkh

Date: 2026-10-27 13:50

To: [email protected]

CC stable; tuan.zhang; jianxin.pan

Subject: Re: mm: call the security_mmap_file() LSM hook in remap_file_pages()

[ EXTERNAL EMAIL ]

Quoted 88 lines · On Tue, Oct 27, 2026 at 11:37:21AM +0800, [email protected] wrote:

Dear 5.15.y maintainers,

An mm patch should be backported from upstream mainline to the stable

5.15.y branch. The patch's information is shown as below:

[Subject]

mm: call the security_mmap_file() LSM hook in remap_file_pages()

[Upstream commit ID]

0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1

[Kernel version]

5.15.y

[Why]

The remap_file_pages syscall handler calls do_mmap() directly, which

doesn't contain the LSM security check. And if the process has called

personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for

RW pages, this will actually result in remapping the pages to RWX,

bypassing a W^X policy enforced by SELinux.

So we should check prot by security_mmap_file LSM hook in the

remap_file_pages syscall handler before do_mmap() is called. Otherwise, it

Quoted 5 lines

potentially permits an attacker to bypass a W^X policy enforced by

SELinux.

Please provide a working backport that you have tested for this, as it

does not apply cleanly on its own.

Also note that 5.15.y will only be alive for one more month, so why

aren't you moving off of this kernel version already instead of wanting

to add a new bugfix to it when there are already 2000+ unfixed CVEs in

that tree?

thanks,

greg k-h

author maintainer
#3 lore raw
Quoted 10 lines · On Tue, Oct 27, 2026 at 02:44:41PM +0800, [email protected] wrote:

Hi gregkh

I have verified the following:

1. The patch can be applied to the linux-5.15.y branch. The commit applies cleanly on top of v5.15.223 (using git cherry-pick -x, with no conflicts):

git cherry-pick -x 0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1 with no conflicts

But that is not the original commit, please do this on the original.

And again, please provide a tested backport and we will be glad to include it.

Quoted 3 lines

2. Our customer is using the 5.15.y branch The customer has requested the inclusion of these CVEs. and is unwilling to upgrade to version 6.x or higher.

Then you have tested this already? Also what will they do in December?

Quoted 2 lines

Furthermore, as they are using GKI 2.0, they cannot apply "autopatch." the only way to incorporate fixes for CVEs is by updating the LTS.

I have no idea what this means at all, sorry.

greg k-h

#4 lore raw

Hi gregkh

Quoted 1 line

original commit:

ea7e2d5e49c05e5db1922387b09ca74aa40f46e2
If use the original commit, there will be conflicts
that need to be resolved manually.

Quoted 1 line

Then you have tested this already? Also what will they do in December?

The customer currently plans to use only 5.15.

I`d like to ask a few questions:
1, What is a "tested backport"?
Is this for verifying code BUILD and kernel bootup? or
Reproduce the issue and verify that the patch is effective?

2, How should I provide the "tested backport" to you? As a patch file?
or
as a link?

Thanks,
-------------------------------
From: gregkh

Date: 2026-10-27 14:50

To: [email protected]

CC stable; tuan.zhang; jianxin.pan

Subject: Re: mm: call the security_mmap_file() LSM hook in remap_file_pages()

[ EXTERNAL EMAIL ]

Quoted 32 lines · On Tue, Oct 27, 2026 at 02:44:41PM +0800, [email protected] wrote:

Hi gregkh

I have verified the following:

1. The patch can be applied to the linux-5.15.y branch.

The commit applies cleanly on top of v5.15.223

(using git cherry-pick -x, with no conflicts):

Quoted 5 lines

git cherry-pick -x 0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1

with no conflicts

But that is not the original commit, please do this on the original.

And again, please provide a tested backport and we will be glad to

include it.

Quoted 9 lines

2. Our customer is using the 5.15.y branch

The customer has requested the inclusion of these CVEs.

and is unwilling to upgrade to version 6.x or higher.

Then you have tested this already?  Also what will they do in December?

Quoted 5 lines

Furthermore, as they are using GKI 2.0, they cannot apply "autopatch."

the only way to incorporate fixes for CVEs is by updating the LTS.

I have no idea what this means at all, sorry.

greg k-h

maintainer Applied
#5 lore raw
Quoted 2 lines

If use the original commit, there will be conflicts
that need to be resolved manually.

The original can't go to 5.15 on its own. ea7e2d5e49c0 ("mm: call the security_mmap_file() LSM hook in remap_file_pages()") calls security_mmap_file() under the mmap write lock, which creates a lock inversion with IMA. That is fixed by 58a039e679fe ("mm: split critical region in remap_file_pages() and invoke LSMs in between"). Greg dropped the earlier 5.15 and 5.10 backports in February 2025 for leaving it out, and 6.1.y has carried the original without it since 6.1.120.

I've queued 58a039e679fe for 6.1. For 5.15 the backport has to be the two commits as a pair: the original, then 58a039e679fe.

Quoted 4 lines

1, What is a "tested backport"?
Is this for verifying code BUILD and kernel bootup? or
Reproduce the issue and verify that the patch is effective?

At minimum, build and boot 5.15.y with both patches applied. If you can reproduce the original problem, please also confirm it is gone.

Quoted 4 lines

2, How should I provide the "tested backport" to you? As a patch file?
or
as a link?

Send them inline with git send-email to [email protected], one mail per patch, with [PATCH 5.15.y] in the subject. Each commit message needs the upstream commit ID, and a note on anything you changed from it. See Option 3 in Documentation/process/stable-kernel-rules.rst.

Signature · 2 lines
Thanks,
Sasha
#6 lore raw

Hi sashal , gregkh

1, Based on 5.15.y, I tested these two patches;
the kernel BUILD successfully and kernel bootup without any issues.

2, Submitted two patches via git send-email. ea7e2d5e49c0:
Message-ID: <[email protected]>

58a039e679fe:
Message-ID: <[email protected]>

Submit to
https://lore.kernel.org/stable/

Thanks,

--------------

Quoted 145 lines

[ EXTERNAL EMAIL ]

Quoted 5 lines

If use the original commit, there will be conflicts

  that need to be resolved manually.

The original can't go to 5.15 on its own. ea7e2d5e49c0 ("mm: call the

security_mmap_file() LSM hook in remap_file_pages()") calls

security_mmap_file() under the mmap write lock, which creates a lock inversion

with IMA. That is fixed by 58a039e679fe ("mm: split critical region in

remap_file_pages() and invoke LSMs in between"). Greg dropped the earlier 5.15

and 5.10 backports in February 2025 for leaving it out, and 6.1.y has carried

the original without it since 6.1.120.

I've queued 58a039e679fe for 6.1. For 5.15 the backport has to be the two

commits as a pair: the original, then 58a039e679fe.

Quoted 8 lines

1, What is a "tested backport"?

Is this for verifying code BUILD and kernel bootup?

Quoted 5 lines

or

Reproduce the issue and verify that the patch is effective?

At minimum, build and boot 5.15.y with both patches applied. If you can

reproduce the original problem, please also confirm it is gone.

Quoted 8 lines

2, How should I provide the "tested backport" to you?

As a patch file?

Quoted 5 lines

or

as a link?

Send them inline with git send-email to [email protected], one mail per

patch, with [PATCH 5.15.y] in the subject. Each commit message needs the

upstream commit ID and a note on anything you changed from it. See Option 3 in

Documentation/process/stable-kernel-rules.rst.

--

Thanks,

Sasha

#7 lore raw
In reply to a message not in the archive

Dear 5.15.y maintainers,

An mm patch should be backported from upstream mainline to the stable 5.15.y branch. The patch's information is shown as below:

[Subject]
mm: call the security_mmap_file() LSM hook in remap_file_pages()

[Upstream commit ID]
0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1

[Kernel version]
5.15.y

[Why]
The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux.
So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux.

Thanks,
yao.zhang1