[PATCH 03/46] mm/memfd: check for real shmem inodes before accessing shmem state

[David Hildenbrand (Arm)]

On 10/27/26 09:13, Mike Rapoport wrote:
> On Tue, Oct 27, 2026 at 12:17:23AM +0100, David Hildenbrand (Arm) wrote:
>> shmem_file() only checks a file's backing mapping. That mapping can belong
>> to another file, as with a Coda file backed by a tmpfs container after
>> mmap(). It does not establish that file_inode(file) is a shmem inode.
>>
>> Seal handling and memfd preservation use this check before accessing
>> shmem inode state, so they can access an inode of the wrong type.
>>
>> Add file_inode_is_shmem() to check the inode's file operations in both
>> paths. This identifies regular shmem inodes, including those used by
>> memfds and ordinary tmpfs files, independently of wrapper file operations.
>>
>> Fixes: c49fcfcda8b5 ("mm/shmem: update file sealing comments and file checking")
>> Fixes: b3749f174d68 ("mm: memfd_luo: allow preserving memfd")
>> Cc: stable at vger.kernel.org
>> Reported-by: Chris Mason <mason at kernel.org>
>> Signed-off-by: David Hildenbrand (Arm) <david at kernel.org>
> 
> Reviewed-by: Mike Rapoport (Microsoft) <rppt at kernel.org>
> 
> With a small nit below
> 
>> ---
>>  include/linux/shmem_fs.h | 6 ++++++
>>  mm/memfd.c               | 8 +++++---
>>  mm/memfd_luo.c           | 2 +-
>>  mm/shmem.c               | 5 +++++
>>  4 files changed, 17 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
>> index a7c7a96a7cbf9..2ceca7993e4f5 100644
>> --- a/include/linux/shmem_fs.h
>> +++ b/include/linux/shmem_fs.h
>> @@ -117,8 +117,14 @@ extern unsigned long shmem_get_unmapped_area(struct file *, unsigned long addr,
>>  		unsigned long len, unsigned long pgoff, unsigned long flags);
>>  extern int shmem_lock(struct file *file, int lock, struct ucounts *ucounts);
>>  #ifdef CONFIG_SHMEM
>> +bool file_inode_is_shmem(const struct inode *inode);
> 
> Do we really need the file_ prefix in this name?

Good point, I intuitively added it. Can drop.

Thanks!

-- 
Cheers,

David