CVE-2026-97986: virtio_input: stop callbacks before unregistering input device

Published Sep 25, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

virtioinput: stop callbacks before unregistering input device

virtinputremove() unregisters the input device before resetting the virtio device. virtinputrecvevents() drops vi->lock around inputevent(), 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 virtinputfreeze() already does. With the preceding core change, reset waits for callbacks before inputunregisterdevice() 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, inputunregisterhandle() 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.

Affected Software

1 affected component
Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Operational

    Reset the virtio device before unregistering the input device, so callbacks are stopped before vi->idev is freed.

Event History

Sep 25, 2026
CVE Published
via MITRE·10:23 AM
Data Sourced
via MITRE·10:23 AM
Description
Data Sourced
via NVD·11:17 AM
Description

Frequently Asked Questions

1

Which systems are most likely exposed to this issue?

Systems using the Linux kernel virtio input driver are affected when the virtio input device is removed while event-receive callbacks may still run. PCI and MMIO transports may have the issue masked by an RCU grace period when evdev is attached, but that does not protect sleepable callbacks on other transports.

2

What condition is required to trigger the lifetime issue?

The virtio input device must be unregistered while a receive-events callback has already passed its readiness check. Because the callback drops the driver lock around input event delivery, it can later continue using the input device and requeue or kick virtio buffers after device teardown begins.

3

What is the relevant remediation behavior?

The fix resets the virtio device before unregistering the input device, so reset waits for active callbacks before the input device can be freed. It also rechecks readiness after reacquiring the lock, allowing completed events to drain while preventing buffer requeueing and queue kicks during teardown.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203