Description

In the Linux kernel, the following vulnerability has been resolved: Input: sur40 - fix input device registration ordering In sur40_probe(), input_register_device() was previously called early before the V4L2 video device and vb2_queue components were fully initialized. If userspace opened the input device immediately upon registration, sur40_open() would trigger and start the sur40_poll() worker thread. This worker thread invokes sur40_process_video() and accesses the uninitialized vb2_queue structure, leading to a data race and potential system crash. Furthermore, if V4L2 or video registration failed after input_register_device() succeeded, the error path fell through to calling input_free_device() on a successfully registered device instead of input_unregister_device(), corrupting input core state. Move input_register_device() to the very end of sur40_probe(). This ensures the V4L2 and video queue structures are fully initialized before polling can start, and naturally resolves the error path bug since input_free_device() is now only called when input registration has not yet occurred. To maintain strict LIFO (Last-In, First-Out) teardown ordering, also move input_unregister_device() to the very beginning of sur40_disconnect(). This guarantees that the input polling worker thread is stopped before V4L2 video components or control handlers are unregistered.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T15:17:10.690Z",
  "pubdate": "2026-08-26T15:17:10.690Z",
  "executiveSummary": "A race condition vulnerability exists in the Linux kernel's sur40 driver, specifically within the probe and disconnect routines. This flaw arises from improper ordering during the initialization and teardown of input devices and V4L2 components.\nThe vulnerability allows for potential system instability, including kernel panics or crashes, when userspace applications interact with the input device during the probe sequence. By accessing uninitialized structures, an attacker or a rapid-cycling userspace process can trigger memory corruption.\nThe primary risk involves a local denial-of-service condition. Successful exploitation requires an attacker to have local access to interact with the device node while the driver is in an intermediate initialization state.\nThe vulnerability affects the sur40 driver initialization flow, where input device registration occurred prior to the full instantiation of the V4L2 video device and vb2_queue components. This violates expected object lifecycle management, leading to state corruption and invalid memory access.",
  "technicalDetails": "The root cause of this vulnerability is a violation of the object initialization lifecycle in the sur40_probe function within the Linux kernel input subsystem. Previously, the driver invoked input_register_device() before the V4L2 video infrastructure and the vb2_queue structures were fully prepared.\nThe attack flow begins when userspace monitors for new device nodes. If an application opens the input device immediately upon registration—but before the kernel completes the V4L2 subsystem initialization—the driver’s open handler, sur40_open(), is triggered. This handler initiates the sur40_poll() worker thread.\nBecause the vb2_queue structure is not yet fully initialized when the poll thread starts, the subsequent execution of sur40_process_video() results in an illegal memory access or data race while attempting to interact with the partially initialized V4L2 components. This leads to undefined behavior, typically manifesting as a kernel panic or system crash.\nFurthermore, the error handling logic in sur40_probe was defective. If V4L2 registration failed after a successful input_register_device() call, the driver erroneously invoked input_free_device() on a registered input device. This skipped the required input_unregister_device() call, leading to a corrupted state within the input core, where the kernel maintained references to an invalid or freed device object.\nThe remediation involves moving the input_register_device() call to the conclusion of the sur40_probe routine. This ensures that all critical V4L2 components are fully instantiated before the device becomes reachable and functional to userspace. Additionally, the teardown logic was refactored by moving input_unregister_device() to the start of sur40_disconnect(), ensuring a LIFO-ordered cleanup. This prevents the worker thread from attempting to access video components after they have been marked for destruction or already destroyed, closing the race condition window."
}