In commit 158978945f31 ("mm: perform the mapping_map_writable() check after
call_mmap()") (and preceding changes in the same series) it became possible
to mmap() F_SEAL_WRITE sealed memfd mappings read-only.

Commit 5de195060b2e ("mm: resolve faulty mmap_region() error path
behaviour") unintentionally undid this logic by moving the
mapping_map_writable() check before the shmem_mmap() hook is invoked,
thereby regressing this change.

This series reworks how we both permit write-sealed mappings being mapped
read-only and disallow mprotect() from undoing the write-seal, fixing this
regression.

We also add a regression test to ensure that we do not accidentally regress
this in future.

Thanks to Julian Orth for reporting this regression.

Note that this will require stable backports to 6.6.y and 6.12.y, I will
send these manually when this lands upstream.

Lorenzo Stoakes (2):
  mm: reinstate ability to map write-sealed memfd mappings read-only
  selftests/memfd: add test for mapping write-sealed memfd read-only

 include/linux/memfd.h                      | 14 ++++++
 include/linux/mm.h                         | 58 +++++++++++++++-------
 mm/memfd.c                                 |  2 +-
 mm/mmap.c                                  |  4 ++
 tools/testing/selftests/memfd/memfd_test.c | 43 ++++++++++++++++
 5 files changed, 102 insertions(+), 19 deletions(-)

--
2.47.0

Andrew - This is a hotfix for 6.13, sorry forgot to tag the series as such :)

Thanks!

On Thu, Nov 28, 2024 at 03:06:16PM +0000, Lorenzo Stoakes wrote:
> In commit 158978945f31 ("mm: perform the mapping_map_writable() check after
> call_mmap()") (and preceding changes in the same series) it became possible
> to mmap() F_SEAL_WRITE sealed memfd mappings read-only.
>
> Commit 5de195060b2e ("mm: resolve faulty mmap_region() error path
> behaviour") unintentionally undid this logic by moving the
> mapping_map_writable() check before the shmem_mmap() hook is invoked,
> thereby regressing this change.
>
> This series reworks how we both permit write-sealed mappings being mapped
> read-only and disallow mprotect() from undoing the write-seal, fixing this
> regression.
>
> We also add a regression test to ensure that we do not accidentally regress
> this in future.
>
> Thanks to Julian Orth for reporting this regression.
>
> Note that this will require stable backports to 6.6.y and 6.12.y, I will
> send these manually when this lands upstream.
>
> Lorenzo Stoakes (2):
>   mm: reinstate ability to map write-sealed memfd mappings read-only
>   selftests/memfd: add test for mapping write-sealed memfd read-only
>
>  include/linux/memfd.h                      | 14 ++++++
>  include/linux/mm.h                         | 58 +++++++++++++++-------
>  mm/memfd.c                                 |  2 +-
>  mm/mmap.c                                  |  4 ++
>  tools/testing/selftests/memfd/memfd_test.c | 43 ++++++++++++++++
>  5 files changed, 102 insertions(+), 19 deletions(-)
>
> --
> 2.47.0

On Fri, 29 Nov 2024 10:03:51 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

> Andrew - This is a hotfix for 6.13, sorry forgot to tag the series as such :)

Jann's feedback didn't sound very ackish?

On Fri, Nov 29, 2024 at 02:24:33AM -0800, Andrew Morton wrote:
> On Fri, 29 Nov 2024 10:03:51 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
> > Andrew - This is a hotfix for 6.13, sorry forgot to tag the series as such :)
>
> Jann's feedback didn't sound very ackish?

Obviously Jann can indicate whether he feels this needs work or not, but I
believe we resolved the issues raised?

Mostly concerns around expected behaviour for these operations _in general_
and whether mmap-read'ing memfd write sealed mappings make sense, however
it's by the by, we accidentally regressed user-facing behaviour and so
should restore it.

I also feel I made a case for why it is in fact sane and useful to be able
to mmap memfd-write-sealed mappings :)

But of course - Jann can indicate whether he is happy with this or whether
it needs work, as usual his input is excellent and highly appreciated so
Jann - if you have any remaining concerns - please let me know.

Thanks!