> On 24 Jun 2025, at 11:22, David Hildenbrand <[email protected]> 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 <[email protected]>
> 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.
>
> 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?
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 */
before enabling the requested features for this uffd context.
