Re: [RFC PATCH] userfaultfd: allow registration of ranges below mmap_min_addr

["Denis M. Karpov" <komlomal@gmail.com>]

> Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization")
Thank you, I will add this Fixes tag in the next patch.

> Hmm but it looks bit strange to check capability for address that is
> already mapped by mmap(). Why is this required?
Actually, it's not obvious to me either, but I may miss something. My intent was
to replace the current restrictive check with a more flexible one. I think
performing this check here allows us to deny invalid requests early,
before locks or VMA lookups occur.

Removing this check entirely would also allow using UFFD in cases where a task
drops privileges after the initial mmap(). This seems reasonable because the
VMA already exists, i.e. kernel already allowed this mapping.

In the [BUG] thread discussion Andrea Arcangeli also suggested adding
a check for
FIRST_USER_ADDRESS to handle architectural constraints.

Andrea, could you please comment on this? Specifically, would a
check against FIRST_USER_ADDRESS sufficient here, or do we still
need to check caps?



On Wed, Apr 8, 2026 at 6:21 AM Harry Yoo (Oracle) <harry@kernel.org> wrote:
>
> On Tue, Apr 07, 2026 at 11:14:42AM +0300, Denis M. Karpov wrote:
> > The current implementation of validate_range() in fs/userfaultfd.c
> > performs a hard check against mmap_min_addr without considering
> > capabilities, but the mmap() syscall uses security_mmap_addr()
> > which allows privileged processes (with CAP_SYS_RAWIO) to map below
> > mmap_min_addr. Furthermore, security_mmap_addr()->cap_mmap_addr() uses
> > dac_mmap_min_addr variable which can be changed with
> > /proc/sys/vm/mmap_min_addr.
> >
> > Because userfaultfd uses a different check, UFFDIO_REGISTER may fail
> > with -EINVAL for valid memory areas that were successfully mapped
> > below mmap_min_addr even with appropriate capabilities.
> >
> > This prevents apps like binary compilers from using UFFD for valid memory
> > regions mapped by application.
> >
> > Replace the rigid mmap_min_addr check with security_mmap_addr() to align
> > userfaultfd with the standard kernel memory mapping security policy.
>
> Perhaps worth adding
>
> Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization")
>
> > Signed-off-by: Denis M. Karpov <komlomal@gmail.com>
> >
> > ---
> >  fs/userfaultfd.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> > index bdc84e521..dbfe5b2a0 100644
> > --- a/fs/userfaultfd.c
> > +++ b/fs/userfaultfd.c
> > @@ -1238,15 +1238,13 @@ static __always_inline int validate_unaligned_range(
> >               return -EINVAL;
> >       if (!len)
> >               return -EINVAL;
> > -     if (start < mmap_min_addr)
> > -             return -EINVAL;
> >       if (start >= task_size)
> >               return -EINVAL;
> >       if (len > task_size - start)
> >               return -EINVAL;
> >       if (start + len <= start)
> >               return -EINVAL;
> > -     return 0;
> > +     return security_mmap_addr(start);
>
> Hmm but it looks bit strange to check capability for address that is
> already mapped by mmap(). Why is this required?
>
> >  }
>
> --
> Cheers,
> Harry / Hyeonggon