Re: [PATCH v2 1/2] mm/memfd_luo: carry the sealed exec-bit state in the preserved record

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm: data race on SHMEM_I(inode)->flags via SysV SHM LUO preservation
--

commit e3ce8882f8b9c8b13e7c221a9ec8a0c481093c2f
Author: Haolong Wang <18766350203@163.com>

mm/memfd_luo: carry the sealed exec-bit state in the preserved record

This commit extends the memfd live update (LUO) preservation to record
the exact execute permission bits. This ensures that the restored memfd
retains its original execution state and seal protection, rather than
reverting to a default that might invert the W^X guarantee. It also adds
a compatibility layer for older record versions.

> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index e729b9b0e38d4..40e1ce87c30e0 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
[ ... ]
> @@ -208,6 +214,20 @@ static inline void shmem_freeze(struct inode *inode, bool freeze)
>  		SHMEM_I(inode)->flags &= ~SHMEM_F_MAPPING_FROZEN;
>  }
>  
> +/* Must be called with inode lock taken exclusive. */
> +static inline void shmem_freeze_seal_state(struct inode *inode, bool freeze)
> +{
> +	if (freeze)
> +		SHMEM_I(inode)->flags |= SHMEM_F_SEAL_STATE_FROZEN;
> +	else
> +		SHMEM_I(inode)->flags &= ~SHMEM_F_SEAL_STATE_FROZEN;
> +}

[Severity: Medium]
Is it possible for this non-atomic flag update to race with SysV SHM?

The LUO memfd handler's can_preserve check admits files if they are
shmem_file() and have no links. SysV SHM files are internally created
as unlinked shmem files, meaning a user can obtain a file descriptor
for an attached SysV SHM segment via /proc/self/map_files/ and pass it
to the LUO preservation ioctl.

If a SysV SHM file reaches this freeze path, shmem_freeze_seal_state()
modifies SHMEM_I(inode)->flags using non-atomic bitwise operations
under inode_lock. Concurrently, a user can call shmctl(SHM_LOCK) which
modifies the exact same flags field via shmem_lock() while holding only
the ipc_lock_object spinlock.

Could this concurrent read-modify-write cause lost flag updates,
potentially bypassing the LUO seal freeze state or corrupting the SysV
SHM locked state?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014031254.432582-1-18766350203@163.com?part=1