CVE-2025-68822

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: alps - fix use-after-free bugs caused by dev3_register_work<br /> <br /> The dev3_register_work delayed work item is initialized within<br /> alps_reconnect() and scheduled upon receipt of the first bare<br /> PS/2 packet from an external PS/2 device connected to the ALPS<br /> touchpad. During device detachment, the original implementation<br /> calls flush_workqueue() in psmouse_disconnect() to ensure<br /> completion of dev3_register_work. However, the flush_workqueue()<br /> in psmouse_disconnect() only blocks and waits for work items that<br /> were already queued to the workqueue prior to its invocation. Any<br /> work items submitted after flush_workqueue() is called are not<br /> included in the set of tasks that the flush operation awaits.<br /> This means that after flush_workqueue() has finished executing,<br /> the dev3_register_work could still be scheduled. Although the<br /> psmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),<br /> the scheduling of dev3_register_work remains unaffected.<br /> <br /> The race condition can occur as follows:<br /> <br /> CPU 0 (cleanup path) | CPU 1 (delayed work)<br /> psmouse_disconnect() |<br /> psmouse_set_state() |<br /> flush_workqueue() | alps_report_bare_ps2_packet()<br /> alps_disconnect() | psmouse_queue_work()<br /> kfree(priv); // FREE | alps_register_bare_ps2_mouse()<br /> | priv = container_of(work...); // USE<br /> | priv-&gt;dev3 // USE<br /> <br /> Add disable_delayed_work_sync() in alps_disconnect() to ensure<br /> that dev3_register_work is properly canceled and prevented from<br /> executing after the alps_data structure has been deallocated.<br /> <br /> This bug is identified by static analysis.