On 24.06.25 13:29, Nadav Amit wrote:
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.
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
