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

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

[gregkh]

On Tue, Oct 27, 2026 at 11:37:21AM +0800, yao.zhang1@amlogic.com 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
> 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

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

[yao.zhang1]

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

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

[yao.zhang1]

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: yao.zhang1@amlogic.com



CC: stable; tuan.zhang; jianxin.pan



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



[ EXTERNAL EMAIL ]



 



On Tue, Oct 27, 2026 at 11:37:21AM +0800, yao.zhang1@amlogic.com 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



> 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

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

[gregkh]

On Tue, Oct 27, 2026 at 02:44:41PM +0800, yao.zhang1@amlogic.com 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.

> 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?

> 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

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

[yao.zhang1]

Hi gregkh

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

> 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: yao.zhang1@amlogic.com



CC: stable; tuan.zhang; jianxin.pan



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



[ EXTERNAL EMAIL ]



 



On Tue, Oct 27, 2026 at 02:44:41PM +0800, yao.zhang1@amlogic.com 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.





> 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?





> 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

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

[Sasha Levin]

> 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.

> 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.

> 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 stable@vger.kernel.org, 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

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

[yao.zhang1]

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: <20261028080719.1821-1-yao.zhang1@amlogic.com>

58a039e679fe:
Message-ID: <20261028080835.1852-1-yao.zhang1@amlogic.com>

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


Thanks, 


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


>[ EXTERNAL EMAIL ]



>



>> 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.



>



>> 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.



>



>> 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 stable@vger.kernel.org, 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