Re: [PATCH v2 3/3] proc: 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:
- [Critical] A TOCTOU race allows a newly mmap'd VMA to bypass the zapping process during device rundown, leaving active PTEs mapped to removed hardware.
--

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

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

This commit unmaps user space mappings associated with removable proc
entries when the entry is being removed. It does this by calling
unmap_mapping_file() in close_pdeo() for each open file.

> diff --git a/fs/proc/inode.c b/fs/proc/inode.c
> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -239,6 +239,8 @@ static void close_pdeo(struct proc_dir_entry *pde, struct pde_opener *pdeo)
>  		spin_unlock(&pde->pde_unload_lock);
>  
>  		file = pdeo->file;
> +		if (pde_is_removed(pde))
> +			unmap_mapping_file(file);

[Severity: Critical]
Can this race with a concurrent mmap() operation?

Looking at proc_reg_mmap() in fs/proc/inode.c, the PDE usage count is
dropped before the VMA is linked into the address space:

fs/proc/inode.c:proc_reg_mmap() {
    ...
    rv = pde_mmap(pde, file, vma);
    unuse_pde(pde);
    return rv;
}

If Thread A drops the usage count via unuse_pde(), Thread B's rundown
could proceed and execute unmap_mapping_file() here.

Because Thread A has not yet returned to the VFS layer to link the VMA
to the interval tree:

mm/vma.c:__mmap_new_vma() {
    ...
    vma_link_file(vma, action->hide_from_rmap_until_complete);
    ...
}

Would unmap_mapping_file() miss this new VMA, allowing Thread A to return
to userspace with an active mapping to the removed device?

>  		pde->proc_ops->proc_release(file_inode(file), file);
>  
>  		spin_lock(&pde->pde_unload_lock);

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