Cloudanix VulnDB

CVE-2026-80768

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the way the operating system talks to certain hardware devices can let a bad device overwrite internal memory, potentially crashing the system or allowing an attacker with physical access to gain more control.

Exploitation
Physical Access
Attacker needs
Physical Access
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition between ft260_i2c_read and ft260_raw_event allows a device-controlled memcpy into a stack buffer after the owning stack frame has unwound, producing a bounded write to freed stack memory.

Why it matters to the business

Kernel memory corruption reachable from untrusted or malfunctioning HID hardware can lead to system instability or local privilege escalation on affected Linux systems; the low exploitability reduces immediate ransomware risk but still requires prompt patching in device-facing environments.

How an attack unfolds

An attacker supplies a slow or malicious ft260 HID device that delays its I2C read response past the five-second timeout; once the read path times out and returns, the subsequent device event triggers ft260_raw_event to write attacker-controlled bytes into the now-invalid stack location.

How to fix it

Update to a kernel containing the spinlock serialization fix for read_buf, read_idx and read_len; rebuild and reboot all systems using the ft260 HID driver.

How to confirm the fix worked

Confirm the presence of the dedicated spinlock around the NULL check, memcpy and index update in ft260_raw_event and the corresponding locking in ft260_i2c_read; run kernel selftests or fuzzing that exercises I2C read races with delayed responses.

Typical attack path

  1. Attach or emulate a malicious ft260-compatible HID device
  2. Trigger an I2C read operation that arms the completion and waits
  3. Delay the device response until after timeout and buffer teardown
  4. Deliver a payload via the HID input path that passes the NULL check and performs the write

How to detect it

Search kernel logs and audit trails for repeated ft260 I2C timeout messages followed by unexpected stack or memory corruption reports; inspect USB HID event traces for devices that consistently exceed the five-second response window.

What your security team should do

  • Prioritize kernel updates on systems that expose the ft260 driver to untrusted USB/HID devices
  • Audit custom or embedded kernels for local ft260 patches and backport the spinlock fix if upgrade is delayed
  • Monitor EPSS and KEV status for any future increase in exploit activity

The record

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.

Affected packages

Ecosystem Package Introduced Fixed