Re: [PATCH v2] selftests/mm: Fix UFFDIO_API usage with proper two-step feature negotiation

[David Hildenbrand <david@redhat.com>]

On 24.06.25 13:29, Nadav Amit wrote:
> 
> 
>> On 24 Jun 2025, at 11:22, David Hildenbrand <david@redhat.com> wrote:
>>
>> On 24.06.25 10:07, David Hildenbrand wrote:
>>>>
>>> Is that actually required?
>>> The man page explicitly documents:
>>> "       EINVAL A  previous  UFFDIO_API  call already enabled one or more
>>> features for this userfaultfd.  Calling UFF‐
>>>                 DIO_API twice, the first time with no features set, is
>>> explicitly allowed as per the two-step  feature
>>>                 detection handshake.
>>> "
>>> So if that doesn't work, something might be broken.
>>
>> CCing Nadav and Peter:
>>
>> Could it be that
>>
>> commit 22e5fe2a2a279d9a6fcbdfb4dffe73821bef1c90
>> Author: Nadav Amit <nadav.amit@gmail.com>
>> Date:   Thu Sep 2 14:58:59 2021 -0700
>>
>>     userfaultfd: prevent concurrent API initialization
>>         userfaultfd assumes that the enabled features are set once and never
>>     changed after UFFDIO_API ioctl succeeded.
>>         However, currently, UFFDIO_API can be called concurrently from two
>>     different threads, succeed on both threads and leave userfaultfd's
>>     features in non-deterministic state.  Theoretically, other uffd operations
>>     (ioctl's and page-faults) can be dispatched while adversely affected by
>>     such changes of features.
>>         Moreover, the writes to ctx->state and ctx->features are not ordered,
>>     which can - theoretically, again - let userfaultfd_ioctl() think that
>>     userfaultfd API completed, while the features are still not initialized.
>>         To avoid races, it is arguably best to get rid of ctx->state.  Since there
>>     are only 2 states, record the API initialization in ctx->features as the
>>     uppermost bit and remove ctx->state.
>>
>> Accidentally broke the documented two-step handshake in the man page where we
>> can avoid closing + reopening the fd?
> 
> I agree the code is not correct (and my patch didn’t address this issue),
> but I don’t see it broke it either.
> 
> Unless I’m missing something the code before my patch, when
> uffdio_api.features == 0, also set ctx->state to UFFD_STATE_RUNNING, which
> meant another invocation would see (ctx->state != UFFD_STATE_WAIT_API) and
> fail.

You might be right, I only checked the cmpxchg, assuming it was working 
before that.

... but staring at the history of the "ctx->state = 
UFFD_STATE_RUNNING;", I am not sure if it ever behaved that way.

Do maybe, the man page is simply wrong (although I wonder why that case 
was described that detailed)

> 
>>
>> Without testing, the following might fix it if I am right:
>>
>> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
>> index 22f4bf956ba1c..f03e7c980e1c5 100644
>> --- a/fs/userfaultfd.c
>> +++ b/fs/userfaultfd.c
>> @@ -1944,9 +1944,9 @@ static int userfaultfd_move(struct userfaultfd_ctx *ctx,
>> static int userfaultfd_api(struct userfaultfd_ctx *ctx,
>>                            unsigned long arg)
>> {
>> +       unsigned int new_features, old_features = 0;
>>         struct uffdio_api uffdio_api;
>>         void __user *buf = (void __user *)arg;
>> -       unsigned int ctx_features;
>>         int ret;
>>         __u64 features;
>> @@ -1990,9 +1990,12 @@ static int userfaultfd_api(struct userfaultfd_ctx *ctx,
>>                 goto out;
>>          /* only enable the requested features for this uffd context */
>> -       ctx_features = uffd_ctx_features(features);
>> +       new_features = uffd_ctx_features(features);
>> +       /* allow two-step handshake */
>> +       if (userfaultfd_is_initialized(ctx))
>> +               old_features = UFFD_FEATURE_INITIALIZED;
>>         ret = -EINVAL;
>> -       if (cmpxchg(&ctx->features, 0, ctx_features) != 0)
>> +       if (cmpxchg(&ctx->features, old_features, new_features) != old_features)
>>                 goto err_out;
>>          ret = 0;
> 
> I am not sure it is right since you would return EINVAL in this case.
> It also looks a bit overly complicated - are you concerned about a race?

Yes.

> My whole concern about race was that somebody would exploit it to
> overcome non-cooperative UFFD (IIRC).
> 
> So perhaps just add a check for the case features if 0 and be done with
> it? Something like adding:
> 
> 	ret = 0;
> 	if (ctx->features == 0 && features == 0)
> 		goto err_out; 		/* no error but copying of uffdio_api required */

Probably would also work. But let's find out first if we even want to 
fix this, given that it never seemed to have behaved that way from a 
quick glimpse.

-- 
Cheers,

David / dhildenb