CVE-2026-97992: vhost-vdpa: protect config_ctx from being freed under the config callback
In the Linux kernel, the following vulnerability has been resolved:
vhost-vdpa: protect configctx from being freed under the config callback
vhostvdpaconfigcb() loads v->configctx and signals it without taking a reference and without holding any lock:
struct eventfdctx configctx = v->configctx;
if (configctx) eventfdsignal(configctx);
VHOSTVDPASETCONFIGCALL replaces that field and drops what is normally the last reference to the old context:
swap(ctx, v->configctx);
if (ctx) eventfdctxput(ctx);
eventfdctxput() 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 vhostdev.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->configctx"), which was about vhostvdpaconfigput() 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). VDUSEDEVINJECTCONFIGIRQ queues dev->inject, and vdusedevirqinject() runs the callback under VDUSE's own dev->irqlock, which vhost does not hold. vdusedevreset() does flushwork(&dev->inject), but VHOSTVDPASETCONFIGCALL 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 nativequeuedspinlockslowpath Read of size 4 at addr ffff888107d21808 by task kworker/u17:1/2993 Workqueue: vduse-irq vdusedevirqinject Call Trace: nativequeuedspinlockslowpath+0x97/0x5b0 rawspinlockirqsave+0xd4/0xe0 eventfdsignalmask+0x69/0x120 vhostvdpaconfigcb+0x34/0x50 vdusedevirqinject+0x46/0x60 processonework+0x468/0x950
Allocated by task 2992: doeventfd+0x50/0x200 x64syseventfd2+0x2e/0x40
Freed by task 2992: eventfdctxput+0xb9/0xc0 vhostvdpaunlockedioctl+0x116c/0x2190
Add a spinlock covering every access to configctx, 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 setconfigcb() implementations only VDUSE takes a lock, the rest store the pointer unlocked, so that would not order against an in-flight invocation.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Add a spinlock covering every access to v->config_ctx, including the read in vhost_vdpa_config_cb() and the swap/update in vhost_vdpa_config_put(), so the callback cannot dereference a freed eventfd context.
Event History
Frequently Asked Questions
Which deployments have a documented userspace-reachable path?
Deployments using VDUSE as the vhost-vdpa parent have a userspace-reachable path to this race. The provided information does not identify other parent implementations as userspace-reachable.
What condition triggers the unsafe access?
The race occurs when vhost_vdpa_config_cb() reads and later signals the current config eventfd context while VHOST_VDPA_SET_CONFIG_CALL concurrently replaces that context and drops its final reference. The callback runs in the parent’s interrupt or workqueue context, while the ioctl is handled under vhost_dev.mutex, so the two operations do not share a protecting lock.