From nobody Tue Sep 29 13:19:44 2026 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 95F183E638E for ; Fri, 7 Aug 2026 10:00:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.178 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786096855; cv=none; b=NudTY7JvNgk5U10ebRdu1e/EgwO/9ox+dQp4S/GiAvtya9g3t+N9GT9FKEZf2h03O5FR2Vq58vi+j0pOkja9TLzFk/6hpiB/1qpLmAb5HUrAtGgjgMrgoyXd7L/lwZQf1e/f0LadrhqS6Oo5y4pXx2QDVtojvQuO3gNawU+xUko= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786096855; c=relaxed/simple; bh=MCXM2XKBVlX/EwXo9DZCvLtvoatevzZ4S5wRf3peb1Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eeVCjsgyAPK43+7yPwfge35vMsj8PsmcwNK9e/MBBr6KQerzj7C9CxCddZIM9+EPsgPO5l+qSBsNTTc06mLtTWQEv39yZribRKzryUX/imf08plajn03/ILEhyJo/Q5uIJSuDGi5XAI5gmM+XChHvrT/ttEyP/Tu8GqTapkoXYI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=bG+rNtPy; arc=none smtp.client-ip=209.85.214.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bG+rNtPy" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-2cf452def93so15111195ad.1 for ; Fri, 07 Aug 2026 03:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786096853; x=1786701653; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=mXJlW9JsusO8To5K56BmONAgJx5Sdd1b4tle9i9ZWE8=; b=bG+rNtPyUBAtJ+cL2Lq+M5Zt0zbQ55t7q+ccSZlAhyytJZjsNcJ+WuafaI7kcLTd/K ZtBUpIVy/cJq18W/WSuhGRJSSfZtUWAKIn6dZEp8D7wAfAfKnvV6tZ6aU/Ia2YdG+3yQ 0cC+7mnhptf6ulnAeZ/FtHjgKUkQRQyPOAF/Fa4cdQSseYE9lZA5mJsgrBpu1JOyQHBV UNni/TagtlBMIuJ8FYcbiMRhw5nhPjTff2HwkbP4SBJ8sTf0r533rJ651S01heP7cOEp /xqvI/14JGC+TS+2ow4MV7lRN0VJpajYb8mIHiiAHVyj5f7PRH3bIzzHVyx3XQr29V3I b3XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786096853; x=1786701653; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=mXJlW9JsusO8To5K56BmONAgJx5Sdd1b4tle9i9ZWE8=; b=n1DhcZgkBrjhB1lqClfimcHzwEX0y8QbSQWE91bupo7OI1/GxTg3NjFxNhmdqEh449 USxupuQRF9YtwDi7oo3LWxkGl+EbkI5mSHQCxZBaKrW6u2ljSfwBKy1HSf6vb8E737uB XHvijjxZ0qE0cnF19ypmeYbhIFuc/XvwHFnoESI4zvyr7F75dE8Hp+rOy9VYaZ8ZvoBP R/0Gu+18CRtxIETyj3IlgYzuLqQNKeYSH4c6X9Hf/QyplAZZyfpEGd7/WqpZGp+J2PBv B0UPgxWmmYHepkdjZz9ACOzst447HcmP2gzo+6pXFlcBFSJ51GuLNLZFPR7pYzvfDETj ot2g== X-Forwarded-Encrypted: i=1; AHgh+Rrj3ajIlhoG+Zrl8345u/oJPTlueEx8zBQpHZLaLOlAhZFK6MoDZCNRSLDbkkJmyj7Q7uoy6ukcp2CccCM=@vger.kernel.org X-Gm-Message-State: AOJu0YxZfGtXpXfLThjBGH4UemvnO/t78EeLtaYzRJjk3bP1W6kp4IzC N8lbwwFuNPzYaKi8Kikw8IFGo7f5xtdub+q9IXV/1XERFjj/xpuH4BxR X-Gm-Gg: AR+sD11HApHdpCoNxkpLTXegPck48QJJ+WJ2YPFos7FYlyT/RgPM+TugiLbYByMdGHx UsxWqxUhtCe5hECvWM7YdUwO0JuCRIMx6++tJoYYHSWU0qcRkQhyOcaNEj7XbRiDW8JItfEJnUT hmef/1GxR1+3l/9jMz/kLJl7NtsonWVui6xnARnP0aKMSOBuLL799KY+LrW5uGr2nTgEE7iQNCr R8WudSSEaq/wNmTEGCmJf6UosjhkBsBtC29yTwCYY8CJIiaYfFcvuyv+axAyKWrZAeuGPhH0pVF VdH9UenJ/nwi4btNxvYadrySpY4dnKrnPfLi1CkA1BwjfuOKEXIfQDv/BJPzfpR6VZAGaqTuegx /6iup5GH5aAF1BSY8iV5FjfK2X95DdL7UKhfv3p62r1LyVhOVqs+7lT1PCj7VcFU//orlnI55k0 kZnSCU6eEvwbsWXrOg4Lx2KQ8aSmEhzx15Tv4oFqJmg814UDtXCnHXZ5HdWGod5c+cz1lWXqMo7 65LXP+QjMEWyKWHPEzrM2ebxDHl9PfPPaPQPuMNISZEI6gHYGZHBeM= X-Received: by 2002:a17:902:ce0c:b0:2cc:89ce:2f07 with SMTP id d9443c01a7336-2d0f704ca37mr63534455ad.1.1786096852750; Fri, 07 Aug 2026 03:00:52 -0700 (PDT) Received: from EAIT-H54D9Q2FJQ.eait.uq.edu.au ([130.102.10.60]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d16c4a9f0fsm6500035ad.68.2026.08.07.03.00.47 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 07 Aug 2026 03:00:51 -0700 (PDT) From: Yu Zhang To: mst@redhat.com, jasowangio@gmail.com Cc: eperezma@redhat.com, kvm@vger.kernel.org, virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Yu Zhang Subject: [PATCH 1/2] vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx Date: Fri, 7 Aug 2026 20:00:24 +1000 Message-ID: <20260807100025.19750-2-yuz08559@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260807100025.19750-1-yuz08559@gmail.com> References: <20260807100025.19750-1-yuz08559@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: ctx =3D fd =3D=3D VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); swap(ctx, v->config_ctx); if (!IS_ERR_OR_NULL(ctx)) eventfd_ctx_put(ctx); if (IS_ERR(v->config_ctx)) { long ret =3D PTR_ERR(v->config_ctx); v->config_ctx =3D NULL; return ret; } Commit 0bde59c1723a ("vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails") added that clearing, and spelled out the invariant the rest of the file relies on: "we consider 'v->config_ctx' valid if it is not NULL". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd. Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa") Signed-off-by: Yu Zhang --- drivers/vhost/vdpa.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index ac55275..e5e47f6 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -529,18 +529,14 @@ static long vhost_vdpa_set_config_call(struct vhost_v= dpa *v, u32 __user *argp) return -EFAULT; =20 ctx =3D fd =3D=3D VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); + if (IS_ERR(ctx)) + return PTR_ERR(ctx); + swap(ctx, v->config_ctx); =20 - if (!IS_ERR_OR_NULL(ctx)) + if (ctx) eventfd_ctx_put(ctx); =20 - if (IS_ERR(v->config_ctx)) { - long ret =3D PTR_ERR(v->config_ctx); - - v->config_ctx =3D NULL; - return ret; - } - v->vdpa->config->set_config_cb(v->vdpa, &cb); =20 return 0; --=20 2.43.0 From nobody Tue Sep 29 13:19:44 2026 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9E0EF3955F7 for ; Fri, 7 Aug 2026 10:01:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786096878; cv=none; b=cYgoWggrgJNMLM0P7FmJ+BH8Uq+9yTnCdMi+jWYVem6nBIYWhS9Ut/er5NGkTNqouPjobLeBjvcIHTRVqSplmlsX7Hxf2Mk7Gj7qTatNeYkOubdN35nY4M0GFL2XslLYHve+qP9TqsSaJX5J2Zp9R1F1ZCyqK7BdUr8cstHhQ5Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786096878; c=relaxed/simple; bh=WRblBsIe9oNVkt2I3kyXT3rZMZlv0teuEBRSGedeze4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=P4/iLewYS3FhZOctmZaFAQDD6DiGGXUnxpxbkzK2TgCyg6wLfq83UHWaG9MOn12et7uHcu/FQcJumq2rUwStahEr+W3IUXQwVtLqW6Fw0IF95q5sTt4t/jNQ8edb1+aGWPYGlZzZP9zlvZNbYF+BWael4BHU34BMMEv8pslvPhQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=kV0TBFKo; arc=none smtp.client-ip=209.85.214.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kV0TBFKo" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-2cc61541f8cso21368025ad.0 for ; Fri, 07 Aug 2026 03:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786096876; x=1786701676; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=VHf8GCKQo1jv7HW3zO9fz6VriXYAKorx9FGJYJOkndc=; b=kV0TBFKoicO0hHRC+3FjDW+Me3goGMquK8b8ELRLYpOAWl+7RdgwsAWy0+bQix8G44 rpxT7s8rK0/exXVTiX0zkmbMq8KidOde+WdhIRE4VxMqrBYux6K7fyitC60hGYZn/9Dv 2eE3Q3aVzdmicY6iYxe+wMNwWuCVUkYy6tyQiWVwwqTLquStS4anNLz606uMlOwwQRdY EZbBWzb2O2qozna3BlVlK/iy3MIIIQaLwqZFp46kEb25oMmnrzfNPrd7RWMFvWAXDG08 e3JQmPpO70Ho4eVfH1yLgRwm+IlV8LcSjySmhT3wKaW9wrjoNGaRxawRZEpFVZ0DXXOc S+6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786096876; x=1786701676; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=VHf8GCKQo1jv7HW3zO9fz6VriXYAKorx9FGJYJOkndc=; b=azOB/27LxZ/ssEyu73/CeOglAYIFFGyPTtGTp9qKoqSWsAL1BaVhx0ueOB5YmhTxOT X5Biw2LpcpgI2Y4temZL5BHxn+L0ZORZeKLxODuQds+yrnO0Nk/MaikNGIrBs/sOjVde kNQfOkkEGmb7b6skQyvBr+xL8XzlUxD/Ee5BjSQBssTfJxP56Q0szBcnlvj2DjZlVA4z Ahh4gUU+mR5ClxSEcrWKEhZusdU74D85rKlNcfCWOGJRtTuvsKEr7eR774Ql25RCrD7g tbtlExks+rXgqzW7cA4fHeqO68Nyp1GMwFrZH03or4Of2BNCaesxU53KRVIv9eMEjSmp J0Nw== X-Forwarded-Encrypted: i=1; AHgh+RrdBtyF7j0EbzvgL7LQ0ixYkhXHE5uzO0VnWlOSUmH3rpjsFAq0Zw66QWVF5ddY1upgnV43cBUiGpPFuJI=@vger.kernel.org X-Gm-Message-State: AOJu0Yzyy8G//I5FdnRUrYnulMCdfZr4M/e91Jc4OHMhT9OlzJZHthCZ nMPXmYTt7HCDfwLHuBPFEsnP5eH+sGnsY+KQbfYr4cCmDFqrDFHixaMR X-Gm-Gg: AR+sD133edY6tWxPYk3unWI4hU2Kt5s7TinhMAuoX/tD+rwaKk9Qzaa3kqq3Mw1jAHS +zLrH7MqpnAWuEIGIt1M6fQp7WI+8V7EKMsUBqqJ284TF2lp+ZJZ3tB74lXKJDugf6m9IegX/oW Y2wvyFDn8S0x6ERuiVlS/VQs0OUr9XzMLGn5NX+dQVfg+Pi8Rr4WGhFA+Ggho6nN/LkShKccOnw PxyLd67faP/x9iTfA3CfMZJ9us/1fiqsJ4wH/CPwm7wOfbmUZIDxfREtIoo7wMLhIayIXRF9lbf w74Am1qmsAeM+GSzwgW5pKYTseOm4sxlvyRFDlzEGprMna7WH/jjWB8X51cYuHtx811a1H99hpE V/0BalFVWw7l6BQSxtmdGaZTlv70l8ZaJO8WBSn072dU42HkS4MJUa1SZgCrnhfDhNU3fWHl8Tu 32lBlB2gT3/oWp2o5hBCblhVwyK2jfSVNV4fEBaEXTMgHQJSQzmSC7y/dMfMuxGVdavZh6Z8SIx wN9WdWDfrwZDonaKPgk/YKlLH5646Ufn/4BH3OWSv6bWKT5Blsj8Hlcsm/BIEyB1g== X-Received: by 2002:a17:903:1847:b0:2bf:13af:b077 with SMTP id d9443c01a7336-2d0f70f54bfmr62139835ad.14.1786096875757; Fri, 07 Aug 2026 03:01:15 -0700 (PDT) Received: from EAIT-H54D9Q2FJQ.eait.uq.edu.au ([130.102.10.60]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d16c4a9f0fsm6500035ad.68.2026.08.07.03.01.11 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 07 Aug 2026 03:01:14 -0700 (PDT) From: Yu Zhang To: mst@redhat.com, jasowangio@gmail.com Cc: eperezma@redhat.com, kvm@vger.kernel.org, virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Yu Zhang Subject: [PATCH 2/2] vhost-vdpa: protect config_ctx from being freed under the config callback Date: Fri, 7 Aug 2026 20:00:25 +1000 Message-ID: <20260807100025.19750-3-yuz08559@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260807100025.19750-1-yuz08559@gmail.com> References: <20260807100025.19750-1-yuz08559@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" vhost_vdpa_config_cb() loads v->config_ctx and signals it without taking a reference and without holding any lock: struct eventfd_ctx *config_ctx =3D v->config_ctx; if (config_ctx) eventfd_signal(config_ctx); VHOST_VDPA_SET_CONFIG_CALL replaces that field and drops what is normally the last reference to the old context: swap(ctx, v->config_ctx); if (ctx) eventfd_ctx_put(ctx); eventfd_ctx_put() drops the last kref and frees the context immediately, with no RCU grace period, so a callback that has already loaded the pointer goes on to dereference freed memory. The two sides share no lock: the ioctl runs under vhost_dev.mutex, while the parent invokes the callback from its own interrupt or workqueue context. This is not the reopen refcount underflow fixed by commit f6bbf0010ba0 ("vhost-vdpa: fix use-after-free of v->config_ctx"), which was about vhost_vdpa_config_put() leaving a stale pointer behind. Here the pointer is maintained correctly and it is the read side that is unprotected. With VDUSE as the parent this is reachable from userspace with access to /dev/vduse (root by default). VDUSE_DEV_INJECT_CONFIG_IRQ queues dev->inject, and vduse_dev_irq_inject() runs the callback under VDUSE's own dev->irq_lock, which vhost does not hold. vduse_dev_reset() does flush_work(&dev->inject), but VHOST_VDPA_SET_CONFIG_CALL never goes through reset, so an inject already in flight is not waited for. A process that injects config interrupts on the VDUSE fd while another thread swaps the call fd on the vhost-vdpa fd hits it in seconds: BUG: KASAN: slab-use-after-free in native_queued_spin_lock_slowpath Read of size 4 at addr ffff888107d21808 by task kworker/u17:1/2993 Workqueue: vduse-irq vduse_dev_irq_inject Call Trace: native_queued_spin_lock_slowpath+0x97/0x5b0 _raw_spin_lock_irqsave+0xd4/0xe0 eventfd_signal_mask+0x69/0x120 vhost_vdpa_config_cb+0x34/0x50 vduse_dev_irq_inject+0x46/0x60 process_one_work+0x468/0x950 Allocated by task 2992: do_eventfd+0x50/0x200 __x64_sys_eventfd2+0x2e/0x40 Freed by task 2992: eventfd_ctx_put+0xb9/0xc0 vhost_vdpa_unlocked_ioctl+0x116c/0x2190 Add a spinlock covering every access to config_ctx, so the callback either signals a context that is still alive or observes NULL, and the put happens only once no callback can reach the old value. Clearing the parent's callback before the put would not be enough: of the in-tree set_config_cb() implementations only VDUSE takes a lock, the rest store the pointer unlocked, so that would not order against an in-flight invocation. Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa") Signed-off-by: Yu Zhang --- drivers/vhost/vdpa.c | 32 +++++++++++++++++++++++++------- 1 file changed, 25 insertions(+), 7 deletions(-) diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index e5e47f6..272d506 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -56,6 +56,8 @@ struct vhost_vdpa { int virtio_id; int minor; struct eventfd_ctx *config_ctx; + /* Serialises vhost_vdpa_config_cb() against config_ctx being replaced. */ + spinlock_t config_lock; int in_batch; struct vdpa_iova_range range; u32 batch_asid; @@ -187,10 +189,12 @@ static irqreturn_t vhost_vdpa_virtqueue_cb(void *priv= ate) static irqreturn_t vhost_vdpa_config_cb(void *private) { struct vhost_vdpa *v =3D private; - struct eventfd_ctx *config_ctx =3D v->config_ctx; + unsigned long flags; =20 - if (config_ctx) - eventfd_signal(config_ctx); + spin_lock_irqsave(&v->config_lock, flags); + if (v->config_ctx) + eventfd_signal(v->config_ctx); + spin_unlock_irqrestore(&v->config_lock, flags); =20 return IRQ_HANDLED; } @@ -511,15 +515,22 @@ static long vhost_vdpa_get_vring_num(struct vhost_vdp= a *v, u16 __user *argp) =20 static void vhost_vdpa_config_put(struct vhost_vdpa *v) { - if (v->config_ctx) { - eventfd_ctx_put(v->config_ctx); - v->config_ctx =3D NULL; - } + struct eventfd_ctx *ctx; + unsigned long flags; + + spin_lock_irqsave(&v->config_lock, flags); + ctx =3D v->config_ctx; + v->config_ctx =3D NULL; + spin_unlock_irqrestore(&v->config_lock, flags); + + if (ctx) + eventfd_ctx_put(ctx); } =20 static long vhost_vdpa_set_config_call(struct vhost_vdpa *v, u32 __user *a= rgp) { struct vdpa_callback cb; + unsigned long flags; int fd; struct eventfd_ctx *ctx; =20 @@ -532,8 +543,14 @@ static long vhost_vdpa_set_config_call(struct vhost_vd= pa *v, u32 __user *argp) if (IS_ERR(ctx)) return PTR_ERR(ctx); =20 + spin_lock_irqsave(&v->config_lock, flags); swap(ctx, v->config_ctx); + spin_unlock_irqrestore(&v->config_lock, flags); =20 + /* + * The callback can no longer reach the old context, so this is the + * last reference to it. + */ if (ctx) eventfd_ctx_put(ctx); =20 @@ -1595,6 +1612,7 @@ static int vhost_vdpa_probe(struct vdpa_device *vdpa) } =20 atomic_set(&v->opened, 0); + spin_lock_init(&v->config_lock); v->minor =3D minor; v->vdpa =3D vdpa; v->nvqs =3D vdpa->nvqs; --=20 2.43.0