CVE-2026-80559: Input: sur40 - fix input device registration ordering
In the Linux kernel, the following vulnerability has been resolved:
Input: sur40 - fix input device registration ordering
In sur40probe(), inputregisterdevice() was previously called early before the V4L2 video device and vb2queue components were fully initialized. If userspace opened the input device immediately upon registration, sur40open() would trigger and start the sur40poll() worker thread. This worker thread invokes sur40processvideo() and accesses the uninitialized vb2queue structure, leading to a data race and potential system crash.
Furthermore, if V4L2 or video registration failed after inputregisterdevice() succeeded, the error path fell through to calling inputfreedevice() on a successfully registered device instead of inputunregisterdevice(), corrupting input core state.
Move inputregisterdevice() to the very end of sur40probe(). This ensures the V4L2 and video queue structures are fully initialized before polling can start, and naturally resolves the error path bug since inputfreedevice() is now only called when input registration has not yet occurred.
To maintain strict LIFO (Last-In, First-Out) teardown ordering, also move inputunregisterdevice() to the very beginning of sur40disconnect(). This guarantees that the input polling worker thread is stopped before V4L2 video components or control handlers are unregistered.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In sur40_probe(), move the input_register_device() call to the very end so that teardown ordering and initialization are correct and V4L2/video components are fully initialized before polling starts.
Linux kernel (Input: sur40 driver) input_register_device() call order relative to sur40_probe() = Move input_register_device() to the very end of sur40_probe() - Configuration
In sur40_disconnect(), move the input_unregister_device() call to the very beginning of sur40_disconnect() to ensure the input polling worker thread is stopped before V4L2 input core state changes, and to prevent sur40_process_video() from accessing uninitialized vb2_queue structures.
Linux kernel (Input: sur40 driver) input_unregister_device() call order relative to sur40_disconnect() = Move input_unregister_device() to the very beginning of sur40_disconnect()
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel sur40 input driver are exposed when the associated device is present and the driver is probed. The race requires userspace to open the registered input device before V4L2 video-device and vb2 queue initialization completes.
What is the practical impact of triggering the race?
The polling worker can access an uninitialized vb2_queue, causing a data race and potentially crashing the system. A separate probe-error path can corrupt input-core state if later V4L2 or video registration fails after input-device registration.
Is there a workaround if the fix cannot be deployed immediately?
The provided data identifies userspace opening the input device immediately after registration as the condition that starts polling before initialization is complete. Avoiding use of the sur40 input device during driver initialization may reduce exposure, but no complete workaround is specified.