CVE-2026-80768 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
HID: ft260: fix stack-use-after-return write in I2C read race
ft260_i2c_read() points dev->read_buf 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 ft260_raw_event() 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->read_buf after a plain NULL check.
These two paths share read_buf, read_idx and read_len with no serialization. If the device delays its response until the read times out, ft260_i2c_read() resets the controller, clears read_buf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260_raw_event() 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 read_buf, read_idx and read_len. ft260_raw_event() 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in the Linux kernel HID driver for FTDI FT260 devices represents a critical concurrency flaw involving stack-use-after-return conditions triggered by race conditions during I2C communication operations. The core of this issue lies in the improper synchronization between two distinct execution paths within the ft260 driver: the synchronous read path managed by ft260_i2c_read and the asynchronous input callback handled by ft260_raw_event which operates within the interrupt or input subsystem context. In normal operation, ft260_i2c_read allocates a buffer on the kernel stack pointed to by dev->read_buf, arms a completion mechanism, and waits for data from the hardware device with a timeout of up to five seconds. Simultaneously, when the device sends data, it triggers an interrupt that invokes ft260_raw_event. This callback function is responsible for copying the incoming payload into the shared read buffer after performing only a basic NULL pointer check to ensure the buffer exists.
The fundamental technical flaw arises because these two paths share critical state variables including read_buf, read_idx, and read_len without any mutual exclusion or serialization mechanisms protecting them from concurrent access. Under specific timing conditions where the hardware device delays its response beyond the five-second timeout window, ft260_i2c_read proceeds to reset the controller, clears the dev->read_buf pointer by setting it to NULL, returns from the function, and consequently unwinds the stack frame in which the original buffer was allocated. This action effectively frees or invalidates the memory location previously used for reading data. However, if a delayed response packet arrives at this precise moment of transition, ft260_raw_event may still pass its initial NULL check depending on exact timing nuances before the pointer is fully cleared and processed by the caller, leading to a scenario where the callback attempts to write device-controlled payload data into memory that has already been returned to the stack allocator or overwritten during function unwinding.
This race condition results in a bounded but attacker-influenced stack-use-after-return write vulnerability. An adversary with physical access to the USB HID interface could potentially craft malicious responses from the hardware device to exploit this timing window, causing arbitrary writes into kernel stack memory. Such exploitation can lead to information disclosure if sensitive data is leaked through the corrupted buffer, or more severely, privilege escalation and remote code execution if an attacker can control the content written to the stack frame to overwrite return addresses or function pointers. The lack of serialization allows the teardown process in the read path to slip between the existence check and the actual memory copy operation in the interrupt handler, creating a classic time-of-check-to-time-of-use (TOCTOU) race condition exacerbated by improper resource lifecycle management across concurrent execution contexts.
From a classification perspective, this vulnerability aligns with CWE-362 which describes concurrent access using shared resources without adequate locking leading to race conditions, and specifically manifests as CWE-416 regarding use after free scenarios where memory is accessed after it has been made available for reuse. In the context of the MITRE ATT&CK framework, this flaw facilitates techniques associated with Tactic TA0005 Defense Evasion through exploitation of timing windows and potentially Tactic TA0004 Privilege Escalation if the stack corruption allows modification of kernel control flow structures. The vulnerability highlights the dangers of sharing mutable state between interrupt context handlers and process context functions without rigorous synchronization primitives, particularly when dealing with hardware devices that may exhibit unpredictable latency characteristics.
The resolution implemented in the Linux kernel addresses this issue by introducing a dedicated spinlock to serialize all accesses to the shared read buffer variables including read_buf, read_idx, and read_len. This fix ensures that ft260_raw_event holds the lock across the entire sequence of checking for NULL status, performing the memory copy operation, and updating index pointers. Similarly, the synchronous read path acquires the spinlock when arming the completion mechanism and again when clearing the buffer during timeout handling or error recovery. By enforcing mutual exclusion at this granular level, the kernel prevents the race window from existing between the null check and the subsequent write operation. This structural change guarantees that if a timeout occurs and the read path clears the buffer pointer, any concurrent interrupt handler will be blocked until the lock is released after proper cleanup, thereby eliminating the possibility of writing to freed or invalid stack memory locations regardless of hardware response timing anomalies.