Re: [PATCH v2 2/3] kernfs: Unmap mmaps of removed files via file->f_mapping

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] A TOCTOU race condition between mmap() and kernfs_drain_open_files() allows a newly created VMA to escape being zapped, leaving stale physical mappings accessible to user space after device removal.
--

--- Patch [2]: [PATCH v2 2/3] kernfs: Unmap mmaps of removed files via file->f_mapping ---
commit cbf76235c8b2fab1c84f41b35091ff343e6741ef
Author: Krzysztof Wilczyński <kwilczynski@kernel.org>

kernfs: Unmap mmaps of removed files via file->f_mapping

This commit replaces unmap_mapping_range() with unmap_mapping_file()
in kernfs_drain_open_files(). This ensures that only VMAs of the
removed node are zapped, preserving unrelated mappings for PCI resource
and legacy sysfs files that swap their f_mapping.

> diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
> index 8e0e90c933720..eb04439e9c3ec 100644
> --- a/fs/kernfs/file.c
> +++ b/fs/kernfs/file.c
> @@ -815,10 +815,8 @@ void kernfs_drain_open_files(struct kernfs_node *kn)
>  	}
>  
>  	list_for_each_entry(of, &on->files, list) {
> -		struct inode *inode = file_inode(of->file);
> -
>  		if (of->mmapped) {
> -			unmap_mapping_range(inode->i_mapping, 0, 0, 1);
> +			unmap_mapping_file(of->file);

[Severity: High]
This isn't a bug introduced by this patch, but can this race with the VMA
being linked into the interval tree?

If kernfs_fop_mmap() sets of->mmapped = true and drops the active reference,
it can wake up a concurrent kernfs_remove() thread waiting for active
references to drain. 

If that thread calls kernfs_drain_open_files() and sees of->mmapped == true,
it will call unmap_mapping_file() here.

However, since kernfs_fop_mmap() hasn't yet returned to the core mm code
where vma_link_file() is called (like in __mmap_new_vma()), the VMA
might not be in the interval tree yet. Consequently, unmap_mapping_file()
could find nothing to zap, and the mmap syscall subsequently inserts the VMA,
leaving userspace with an active physical mapping to a removed device.

Could the synchronization between the mmap path and kernfs_drain_open_files()
be missing a mechanism to wait for the VMA to be fully linked?

>  			of->mmapped = false;
>  			on->nr_mmapped--;
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260725210549.3716546-1-kwilczynski@kernel.org?part=2