CVE-2026-97993: vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx
In the Linux kernel, the following vulnerability has been resolved:
vhost-vdpa: don't install the eventfdctxfdget() error in configctx
vhostvdpasetconfigcall() swaps the eventfdctxfdget() return value into v->configctx before checking it, so on failure the field briefly holds an ERRPTR:
ctx = fd == VHOSTFILEUNBIND ? NULL : eventfdctxfdget(fd); swap(ctx, v->configctx);
if (!ISERRORNULL(ctx)) eventfdctxput(ctx);
if (ISERR(v->configctx)) { long ret = PTRERR(v->configctx);
v->configctx = NULL; return ret; }
Commit 0bde59c1723a ("vhost-vdpa: set v->configctx to NULL if eventfdctxfdget() fails") added that clearing, and spelled out the invariant the rest of the file relies on: "we consider 'v->configctx' valid if it is not NULL". The window between the swap and the clearing still breaks it. vhostvdpaconfigcb() only tests for NULL, so a config interrupt delivered inside the window hands the ERRPTR to eventfdsignal().
Check the fd before installing it instead. That closes the window and matches how vhostvringioctl() 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.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the issue?
A vhost-vdpa configuration-call file descriptor must be rejected by eventfd_ctx_fdget(), and a configuration interrupt must arrive during the brief interval before the error pointer is cleared from v->config_ctx. The callback only checks whether config_ctx is NULL, so it can pass the error pointer to eventfd_signal().
Are systems using a valid configuration interrupt file descriptor affected by a rejected replacement?
The described behavior indicates that a rejected file descriptor can tear down a configuration interrupt that was already working. The fix validates the new file descriptor before installing it, preserving the existing configuration interrupt when the replacement is rejected.
How can I determine whether a fix is available for my kernel tree?
The supplied stable references identify fixes at commits 388c678639a0cebfd936b3e56c64ac6a371efec2, 65faf9eaa00e408e1406fbcf675c8c8d0e27ff2a, and 6b20b40f020bde236f6b8a08ff88d8653261ec2. Check whether the applicable commit is present in your kernel source or distribution kernel changelog.