CVE-2026-80768: HID: ft260: fix stack-use-after-return write in I2C read race
In the Linux kernel, the following vulnerability has been resolved:
HID: ft260: fix stack-use-after-return write in I2C read race
ft260i2cread() points dev->readbuf at a caller-supplied buffer (often an on-stack variable), arms a completion and waits up to five seconds for the device to return the data. The HID input callback ft260rawevent() runs in the input/IRQ path, independent of the dev->lock mutex held by the read path, and copies the device-supplied payload into dev->readbuf after a plain NULL check.
These two paths share readbuf, readidx and readlen with no serialization. If the device delays its response until the read times out, ft260i2cread() resets the controller, clears readbuf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260rawevent() pass the NULL check and then memcpy() the device-controlled payload into the now-freed stack location, a bounded but attacker-influenced stack-use-after-return write triggerable by malicious or malfunctioning hardware.
Add a dedicated spinlock that serializes every access to readbuf, readidx and readlen. ft260rawevent() now holds it across the NULL check, the memcpy and the index update, while the read path takes it when arming and when clearing the buffer, so the teardown can no longer slip between the check and the copy.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In the HID ft260 driver, add a dedicated spinlock to serialize every access to shared fields read_buf/read_idx/read_len between ft260_i2c_read() and ft260_raw_event(), preventing a NULL-check/memcpy/index-update race that can lead to stack-use-after-return.
Linux kernel HID ft260 driver dev->read_buf access serialization = serialize with a dedicated spinlock - Compensating control
Ensure ft260_i2c_read() resets the controller and clears dev->read_buf when the device response times out (and during teardown), so stale or attacker-influenced payloads are not processed after a race.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel FT260 HID driver and communicating with an FT260 device over I2C are exposed. Exploitation requires malicious or malfunctioning hardware that can delay a device response until an I2C read has timed out.
What is required to trigger the memory-safety flaw?
An I2C read must point the driver's shared read buffer at a caller-supplied buffer, often on the stack, then time out and return. A device response arriving in the race window can cause the HID input callback to copy device-controlled data into that no-longer-valid stack location.
What mitigation is available if an updated kernel cannot be deployed immediately?
The described trigger depends on interaction with malicious or malfunctioning FT260 hardware. Limiting use of untrusted FT260 devices reduces exposure until a kernel containing the synchronization fix can be installed.
How does the fix prevent exploitation?
The fix adds a dedicated spinlock to serialize access to read_buf, read_idx, and read_len. The HID input callback holds the lock across its NULL check and payload copy, preventing it from using a stale buffer pointer while the read path is timing out and clearing it.