Description
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.
Published: 2026-09-04
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Remote Code Execution
Action: Immediate Patch
AI Analysis

Impact

A race condition in the Linux kernel HID ft260 driver allows an attacker to trigger a stack‑use‑after‑return write during an I2C read operation. The vulnerability arises when the read path releases a buffer before the input/IRQ callback copies device data into it, enabling the callback to write payload data into a freed stack location. This bounded but attacker‑controlled write can corrupt kernel memory, potentially allowing privilege escalation or system compromise. This scenario exemplifies a use‑after‑return flaw, which is classified as CWE‑416.

Affected Systems

This issue affects the Linux kernel wherever the HID ft260 driver is compiled. No specific kernel versions are listed, so all releases prior to the fix are potentially impacted.

Risk and Exploitability

The vulnerability is not listed in CISA’s KEV catalog and has no EPSS score available, indicating limited publicly known exploitation. However, the use‑after‑return write is a serious memory‑corruption flaw identified as CWE‑416. Based on the description, the likely attack vector is malicious or malfunctioning hardware sending crafted I2C data after a read timeout, which can trigger the race and lead to kernel memory corruption with the potential for arbitrary code execution or system instability.

Generated by OpenCVE AI on September 4, 2026 at 21:23 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update to a kernel release that includes the ft260 driver fix.
  • Disable or remove the HID ft260 driver if the device is not needed.
  • Restrict or monitor connections of potential malicious or untrusted HID devices to prevent injection of harmful I2C payloads.

Generated by OpenCVE AI on September 4, 2026 at 21:23 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4777-1 linux security update
History

Fri, 04 Sep 2026 21:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Fri, 04 Sep 2026 15:30:00 +0000

Type Values Removed Values Added
Description 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.
Title HID: ft260: fix stack-use-after-return write in I2C read race
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-04T15:12:40.374Z

Reserved: 2026-08-26T14:34:25.791Z

Link: CVE-2026-80768

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-04T16:18:02.227

Modified: 2026-09-04T16:18:02.227

Link: CVE-2026-80768

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-04T21:30:07Z

Weaknesses