Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yu Zhang" <yuz08559@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx
Date: Sat, 08 Aug 2026 10:01:26 +0000	[thread overview]
Message-ID: <20260808100127.CF84C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807100025.19750-2-yuz08559@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Lack of synchronization between `vhost_vdpa_set_config_call()` and the config interrupt handler `vhost_vdpa_config_cb()` leads to a Data Race and a Use-After-Free on `v->config_ctx`.
--

--- Patch [1]: [PATCH 1/2] vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx ---
commit 97c24916f7205e9db996343c66b6d1658f9125bd
Author: Yu Zhang <yuz08559@gmail.com>

vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx

This commit avoids storing an error pointer in the configuration context on
failure. It validates the file descriptor prior to swapping it, preventing
config interrupts from encountering an invalid pointer.

> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -536,18 +536,14 @@ static long vhost_vdpa_set_config_call(struct vhost_vdpa *v, u32 __user *argp)
>  		return  -EFAULT;
>  
>  	ctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd);
> +	if (IS_ERR(ctx))
> +		return PTR_ERR(ctx);
> +
>  	swap(ctx, v->config_ctx);
>  
> -	if (!IS_ERR_OR_NULL(ctx))
> +	if (ctx)
>  		eventfd_ctx_put(ctx);

[Severity: Critical]
This isn't a bug introduced by this patch, but can this sequence lead to a
use-after-free if a config interrupt occurs concurrently?

In the interrupt handler, the pointer is read locklessly:

drivers/vhost/vdpa.c:vhost_vdpa_config_cb() {
    struct eventfd_ctx *config_ctx = v->config_ctx;

    if (config_ctx)
        eventfd_signal(config_ctx);
    ...
}

If the ioctl thread executing vhost_vdpa_set_config_call() swaps out the old
context and immediately calls eventfd_ctx_put(), it might free the context
while the interrupt handler has already read the old pointer but hasn't yet
called eventfd_signal().

Does this code need synchronization before freeing the old eventfd context to
wait for concurrent interrupt handlers to finish?

> -	if (IS_ERR(v->config_ctx)) {
> -		long ret = PTR_ERR(v->config_ctx);
> -
> -		v->config_ctx = NULL;
> -		return ret;
> -	}
> -
>  	v->vdpa->config->set_config_cb(v->vdpa, &cb);
>  
>  	return 0;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807100025.19750-1-yuz08559@gmail.com?part=1

  reply	other threads:[~2026-08-08 10:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 10:00 [PATCH 0/2] vhost-vdpa: fix a use-after-free on the config eventfd Yu Zhang
2026-08-07 10:00 ` [PATCH 1/2] vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx Yu Zhang
2026-08-08 10:01   ` sashiko-bot [this message]
2026-08-07 10:00 ` [PATCH 2/2] vhost-vdpa: protect config_ctx from being freed under the config callback Yu Zhang
2026-08-08 10:01   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260808100127.CF84C1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yuz08559@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox