Re: [PATCH v5 16/18] userfaultfd: add UFFDIO_SET_MODE for runtime sync/async toggle

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Iterating over VMAs on a potentially unstable mm_struct without calling check_stable_address_space(mm) beforehand.
--

commit 8f453481752954b7331f26ca18fe64760d20297c
Author: Kiryl Shutsemau (Meta) <kas@kernel.org>

userfaultfd: add UFFDIO_SET_MODE for runtime sync/async toggle

This commit adds an ioctl to toggle userfaultfd async mode at runtime without
re-registering. It updates the context features locklessly for readers, while
draining in-flight faults by acquiring the mmap_write_lock and calling
vma_start_write() on all armed VMAs.

> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> index f40bf473a6f68..f172ec14a6c84 100644
> --- a/mm/userfaultfd.c
> +++ b/mm/userfaultfd.c

[ ... ]

> @@ -4290,6 +4300,109 @@ static int userfaultfd_rwprotect(struct userfaultfd_ctx *ctx,
>  	return ret;
>  }

[ ... ]

> +static int userfaultfd_set_mode(struct userfaultfd_ctx *ctx,
> +				unsigned long arg)
> +{
> +	struct uffdio_set_mode mode;
> +	struct mm_struct *mm = ctx->mm;

[ ... ]

> +	/*
> +	 * Drain in-flight faults before flipping features. mmap_write_lock()
> +	 * blocks new mmap_read_lock() callers, but per-VMA locked faults
> +	 * (lock_vma_under_rcu() + FAULT_FLAG_VMA_LOCK) that acquired before
> +	 * this point keep running. Calling vma_start_write() on each UFFD-
> +	 * armed VMA waits for those readers to drop, so no in-flight fault
> +	 * can observe the old features after mmap_write_unlock().
> +	 */
> +	mmap_write_lock(mm);
> +	{
> +		struct vm_area_struct *vma;
> +		VMA_ITERATOR(vmi, mm, 0);
> +
> +		for_each_vma(vmi, vma) {

[Severity: Critical]
Does this VMA iteration need to verify the address space is stable?

Since the mm here is accessed via the userfaultfd context (and could be an
external mm_struct), iterating over it without calling
check_stable_address_space(mm) after acquiring the mmap lock might encounter
XA_ZERO_ENTRY markers in the maple tree if the mm was flagged MMF_UNSTABLE
(e.g., from a dup_mmap() failure or the OOM reaper). Accessing
vma->vm_userfaultfd_ctx.ctx on a zero entry could cause a kernel panic.

> +			if (vma->vm_userfaultfd_ctx.ctx == ctx)
> +				vma_start_write(vma);
> +		}
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526130509.2748441-1-kirill@shutemov.name?part=16