PT-2026-85609 · Linux · Linux
CVE-2026-80768
·
Published
2026-09-04
·
Updated
2026-09-04
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux