CVE-2026-80572: Input: byd - synchronize timer deletion before freeing private data
In the Linux kernel, the following vulnerability has been resolved:
Input: byd - synchronize timer deletion before freeing private data
byddisconnect() uses timerdelete() before freeing the driver's private data. This does not wait for a running bydcleartouch() callback, which dereferences the private data and its psmouse pointer. A callback racing with disconnect can therefore access the private data after it has been freed. The timer can also still be re-armed by bydprocessbyte() while the disconnect is in progress.
Use timershutdownsync() before freeing the private data: it waits for a running callback and turns any later re-arm attempt into a no-op.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In byd_disconnect(), ensure synchronization by calling timer_shutdown_sync() before freeing the driver private data; this waits for a running byd_clear_touch() callback and turns any later re-arm attempt (e.g., from byd_process_byte()) into a no-op. Also avoid using timer_delete() before freeing the private data, since byd_disconnect() currently uses timer_delete() and can lead to the callback dereferencing freed private data during disconnect in progress.
Linux kernel (byd input driver) Use timer_shutdown_sync() before freeing private data = timer_shutdown_sync()
Event History
Frequently Asked Questions
Which systems are exposed to this race condition?
Systems using the Linux kernel's byd input driver are exposed when the driver disconnects while its touch-clear timer callback is running or can be re-armed. The issue concerns the driver's private data and associated psmouse pointer during disconnect.
What condition triggers the use-after-free?
A byd_clear_touch() timer callback must race with byd_disconnect(). The disconnect path can free the driver's private data without waiting for a running callback, and byd_process_byte() can re-arm the timer while disconnect is in progress.
What does the fix change?
The fix replaces timer_delete() with timer_shutdown_sync() before freeing private data. This waits for an active callback to finish and makes subsequent attempts to re-arm the timer no-ops.