Re: [SECURITY] mm: mremap/remap_file_pages skip fsnotify pre-content hook

Re: [SECURITY] mm: mremap/remap_file_pages skip fsnotify pre-content hook

[Lorenzo Stoakes (ARM)]

Stop spamming the mailing list with your unfiltered AI slop.

You've sent reports for stuff already fixed. You're reporting non-security
reports as security reports.

You're not even bothering to format your emails properly.

And what you're sending is an unreadable mess.

We have no interest in this, please just stop. Thanks.

--
Cheers, Lorenzo

Re: [SECURITY] mm: mremap/remap_file_pages skip fsnotify pre-content hook

[Jan Kara]

Hello!

On Tue 10-11-26 19:44:43, n3rd wrote:
> 2. Problem description
> The pre-content (HSM) event contract, as stated when the feature was
> introduced, is that for every accessed file range an event covering at
> least this range is generated at least once before the file data is
> accessed. The only hook that emits that event before a mapping is
> established is fsnotify_mmap_perm() in include/linux/fsnotify.h, and its
> only caller in the whole tree is vm_mmap_pgoff() in mm/util.c, i.e. the
> mmap(2) syscall entry. The page-fault level pre-content hook was reverted
> upstream, so the syscall entry hook is the only remaining gate.
> 
> Two paths turn new file ranges into accessible mappings without ever
> reaching that gate. First, the mremap(2) EXPAND path: in-place growth
> goes through expand_vma() and expand_vma_in_place() in mm/mremap.c, and
> move growth through move_vma() and copy_vma() in mm/vma.c; neither
> mm/mremap.c nor mm/vma.c contains any fsnotify_mmap_perm() or
> security_mmap_file() call. Second, the remap_file_pages(2) emulation in
> mm/mmap.c calls security_mmap_file() and then do_mmap(MAP_POPULATE)
> directly, without fsnotify_mmap_perm().

So this is about the useful content of the email. Five pages of text is
really too much noise for this amount of useful information.

Also what you report is indeed a bug but not really a serious security
issue => let's deal with that in a public list.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR