<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/hid/hid-ft260.c, branch linux-7.1.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.1.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.1.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-04-28T16:24:52+00:00</updated>
<entry>
<title>HID: ft260: validate i2c input report length</title>
<updated>2026-04-28T16:24:52+00:00</updated>
<author>
<name>Michael Zaidman</name>
<email>michael.zaidman@gmail.com</email>
</author>
<published>2026-04-11T06:24:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=80c4bbb2b38513e9c3d84805fa61a0ee16d79c45'/>
<id>urn:sha1:80c4bbb2b38513e9c3d84805fa61a0ee16d79c45</id>
<content type='text'>
Add two checks to ft260_raw_event() to prevent out-of-bounds reads
from malicious or malfunctioning devices:

First, reject reports shorter than the 2-byte header (report ID +
length fields). Without this, even accessing xfer-&gt;length on a
1-byte report is an OOB read.

Second, validate xfer-&gt;length against the actual data capacity of
the received HID report. Each I2C data report ID (0xD0 through
0xDE) defines a different report size in the HID descriptor, so the
available payload varies per report. A corrupted length field could
cause memcpy to read beyond the report buffer.

Reported-by: Sebastián Josué Alba Vives &lt;sebasjosue84@gmail.com&gt;
Signed-off-by: Michael Zaidman &lt;michael.zaidman@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.com&gt;
</content>
</entry>
<entry>
<title>HID: ft260: fix 'cast to restricted' kernel CI bot warnings</title>
<updated>2022-11-11T10:09:36+00:00</updated>
<author>
<name>Michael Zaidman</name>
<email>michael.zaidman@gmail.com</email>
</author>
<published>2022-11-05T21:11:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fb5d783b3c66a0110454a54d2f3bcb7dad4309a1'/>
<id>urn:sha1:fb5d783b3c66a0110454a54d2f3bcb7dad4309a1</id>
<content type='text'>
Fix 'cast to restricted' sparse warnings reported by kernel test robot
in https://lore.kernel.org/all/202211021607.ssjymlKi-lkp@intel.com/

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Michael Zaidman &lt;michael.zaidman@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
<entry>
<title>HID: ft260: missed NACK from busy device</title>
<updated>2022-11-11T10:09:36+00:00</updated>
<author>
<name>Michael Zaidman</name>
<email>michael.zaidman@gmail.com</email>
</author>
<published>2022-11-05T21:11:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5afac727defa0b2a3dffb2abd5fb5f594b98d217'/>
<id>urn:sha1:5afac727defa0b2a3dffb2abd5fb5f594b98d217</id>
<content type='text'>
When writing into a slow device like an EEPROM chip, the
controller may exit the busy state before the device releases
the bus. In this case, the ft260_xfer_status returns success
before the data transfer completion.

The patch fixes it by returning from the ft260_xfer_status()
with the "-EAGAIN" on both controller and bus busy status when
appropriate.

It does not apply to the i2c combined transactions when after
the write IO, the controller keeps the bus busy until the read
IO and then between reading IOs to ensure an atomic operation.

Co-developed-by: Germain Hebert &lt;germain.hebert@ca.abb.com&gt;
Signed-off-by: Germain Hebert &lt;germain.hebert@ca.abb.com&gt;
Signed-off-by: Michael Zaidman &lt;michael.zaidman@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
<entry>
<title>HID: ft260: fix a NULL pointer dereference in ft260_i2c_write</title>
<updated>2022-11-11T10:09:36+00:00</updated>
<author>
<name>Michael Zaidman</name>
<email>michael.zaidman@gmail.com</email>
</author>
<published>2022-11-05T21:11:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c2500bdffe5a95fbd0aecdd5be3d2f175ad22f92'/>
<id>urn:sha1:c2500bdffe5a95fbd0aecdd5be3d2f175ad22f92</id>
<content type='text'>
The zero-length passed into the ft260_i2c_write() triggered the
NULL pointer dereference in the debug message on data[0] access.
Since the controller does not support a write of zero length,
let's not allow it.

Before:

$ sudo i2ctransfer -y 13 w0@0x51
Killed

After:

$ sudo i2ctransfer -y 13 w0@0x51
Error: Sending messages failed: Invalid argument

Reported-by: Enrik Berkhan &lt;Enrik.Berkhan@inka.de&gt;
Signed-off-by: Michael Zaidman &lt;michael.zaidman@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
<entry>
<title>HID: ft260: wake up device from power saving mode</title>
<updated>2022-11-11T10:09:36+00:00</updated>
<author>
<name>Michael Zaidman</name>
<email>michael.zaidman@gmail.com</email>
</author>
<published>2022-11-05T21:11:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4b3da6853a619a952e8caf2e8393264dd42ffa27'/>
<id>urn:sha1:4b3da6853a619a952e8caf2e8393264dd42ffa27</id>
<content type='text'>
The FT260 can enter a power saving mode after being idle for longer
than 5 seconds.

When being woken up from power saving mode by an I2C write request,
a possible NACK is not correctly reported by the controller. As a
workaround, the driver will issue an I2C status report two times in
ft260_xfer_status() after the chip has been idle for more than 5s.

Co-developed-by: Enrik Berkhan &lt;Enrik.Berkhan@inka.de&gt;
Signed-off-by: Enrik Berkhan &lt;Enrik.Berkhan@inka.de&gt;
Signed-off-by: Michael Zaidman &lt;michael.zaidman@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
<entry>
<title>HID: ft260: missed NACK from big i2c read</title>
<updated>2022-11-11T10:09:36+00:00</updated>
<author>
<name>Michael Zaidman</name>
<email>michael.zaidman@gmail.com</email>
</author>
<published>2022-11-05T21:11:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=728b117e7862b1eb05c3aad3b2f087b26453d56a'/>
<id>urn:sha1:728b117e7862b1eb05c3aad3b2f087b26453d56a</id>
<content type='text'>
The FT260 controller does not return NACK when performing a big
read (of multiple hid reports size) from a non-existing device
or from the device responding with NACK when it is not ready
to serve the request. However, it responds correctly with NACK
to a read of up to a single hid report size.

To overcome this issue, we split the muli-report read request
into a read of a single HID report of 60 bytes size and a
multi-report read.

Big read of 256 bytes with first read of 60 bytes:

$ sudo ./i2cperf -d 2 -o 2 -s 256 -r 0-0xff 1 0x50 -S

[  +5.633280] ft260_i2c_write_read: off 0x0 rlen 255 wlen 2
[  +0.000006] ft260_i2c_write: rep 0xd0 addr 0x50 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0
[  +0.013205] ft260_xfer_status: bus_status 0x20, clock 100
[  +0.000007] ft260_i2c_read: rep 0xc2 addr 0x50 len 255 rlen 60 flag 0x3
[  +0.010932] ft260_raw_event: i2c resp: rep 0xde len 60
[  +0.004733] ft260_xfer_status: bus_status 0x40, clock 100
[  +0.000006] ft260_i2c_read: rep 0xc2 addr 0x50 len 195 rlen 128 flag 0x0
[  +0.012572] ft260_raw_event: i2c resp: rep 0xde len 60
[  +0.005789] ft260_raw_event: i2c resp: rep 0xde len 60
[  +0.003189] ft260_raw_event: i2c resp: rep 0xd1 len 8
[  +0.004092] ft260_xfer_status: bus_status 0x40, clock 100
[  +0.000010] ft260_i2c_read: rep 0xc2 addr 0x50 len 67 rlen 67 flag 0x4
[  +0.011688] ft260_raw_event: i2c resp: rep 0xde len 60
[  +0.004700] ft260_raw_event: i2c resp: rep 0xd1 len 7
[  +0.004858] ft260_xfer_status: bus_status 0x20, clock 100

Read from non-existing device at address 8. The first 60 read responded
with NACK.

$ sudo ./i2cperf -d 2 -o 2 -s 256 -r 0-0xff 1 0x8 -S
[Oct19 15:37] ft260_i2c_write_read: off 0x0 rlen 255 wlen 2
[  +0.000007] ft260_i2c_write: rep 0xd0 addr 0x8 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0
[  +0.022820] ft260_xfer_status: bus_status 0x20, clock 100
[  +0.000007] ft260_i2c_read: rep 0xc2 addr 0x8 len 255 rlen 60 flag 0x3
[  +0.010658] ft260_raw_event: i2c resp: rep 0xde len 60
[  +0.005965] ft260_xfer_status: bus_status 0x46, clock 100  &lt;-- NACK
[  +0.000009] ft260 0003:0403:6030.0004: i2c bus error: 0x46
[  +0.007784] ft260_i2c_reset: done

Co-developed-by: Enrik Berkhan &lt;Enrik.Berkhan@inka.de&gt;
Signed-off-by: Enrik Berkhan &lt;Enrik.Berkhan@inka.de&gt;
Signed-off-by: Michael Zaidman &lt;michael.zaidman@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
<entry>
<title>HID: ft260: remove SMBus Quick command support</title>
<updated>2022-11-11T10:09:36+00:00</updated>
<author>
<name>Michael Zaidman</name>
<email>michael.zaidman@gmail.com</email>
</author>
<published>2022-11-05T21:11:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3b56ff4820cf9d36a770d01769d5d9a6c3b14891'/>
<id>urn:sha1:3b56ff4820cf9d36a770d01769d5d9a6c3b14891</id>
<content type='text'>
The i2cdetect uses the SMBus Quick command by default to scan devices
on the I2C bus. The FT260 implements an I2C bus controller. The SMBus
is derived from I2C, but there are several differences between the
specifications of the two buses in the areas of timing, protocols,
operation modes, and electrical characteristics.

One of the differences is that the I2C devices allow the slave not
to ACK its slave address, but SMBus requires it to always ACK it as
a mechanism to detect a detachable device’s presence on the bus.
Since FT260 is the I2C bus controller, it does not acknowledge the
SMBus Quick write command, which sends a single bit to the device at
the place of the RD/WR bit.

The ft260 driver attempted to mimic the SMBus Quick Write functionality
by writing a single byte as the SMBus Byte Write command does.

Usually, one byte in the SMBus Quick Write will be fine. However, it may
cause problems with devices with a control register at offset 0, like
i2c muxes, for example, when scanned with the i2cdetect utility.

The i2cdetect with the "-r" option uses the SMBus Read Byte command,
which is a reasonable workaround. To prevent the I2C bus from locking
at write-only devices (most notably clock chips at address 0x69), use
the "-r" option in conjunction with scanning range parameters.

This patch removes the SMBus Quick command support.

$ sudo i2cdetect -y 13
Warning: Can't use SMBus Quick Write command, will skip some addresses
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:
10:
20:
30: -- -- -- -- -- -- -- --
40:
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60:
70:

$ sudo i2cdetect -y -r 13
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Reported-by: Vince Asbridge &lt;VAsbridge@sanblaze.com&gt;
Reported-by: Stephen Shirron &lt;SShirron@sanblaze.com&gt;
Reported-by: Enrik Berkhan &lt;Enrik.Berkhan@inka.de&gt;
Signed-off-by: Michael Zaidman &lt;michael.zaidman@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
<entry>
<title>HID: ft260: skip unexpected HID input reports</title>
<updated>2022-11-11T10:09:36+00:00</updated>
<author>
<name>Michael Zaidman</name>
<email>michael.zaidman@gmail.com</email>
</author>
<published>2022-11-05T21:11:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b7121e3c04440cc2af9cabbabb24efd23741294a'/>
<id>urn:sha1:b7121e3c04440cc2af9cabbabb24efd23741294a</id>
<content type='text'>
The FT260 is not supposed to generate unexpected HID reports. However,
in theory, the unsolicited HID Input reports can be issued by a specially
crafted malicious USB device masquerading as FT260 when the attacker has
physical access to the USB port. In this case, the read_buf pointer points
to the final data portion of the previous I2C Read transfer, and the memcpy
invoked in the ft260_raw_event() will try copying the content of the
unexpected report into the wrong location.

This commit sets the Read buffer pointer to NULL on the I2C Read
transaction completion and checks it in the ft260_raw_event() to detect
and skip the unsolicited Input report.

Reported-by: Enrik Berkhan &lt;Enrik.Berkhan@inka.de&gt;
Signed-off-by: Michael Zaidman &lt;michael.zaidman@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
<entry>
<title>HID: ft260: do not populate /dev/hidraw device</title>
<updated>2022-11-11T10:09:35+00:00</updated>
<author>
<name>Michael Zaidman</name>
<email>michael.zaidman@gmail.com</email>
</author>
<published>2022-11-05T21:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=76e76e7993f3d8da484424135a4a8acf7f3cac0b'/>
<id>urn:sha1:76e76e7993f3d8da484424135a4a8acf7f3cac0b</id>
<content type='text'>
Do not populate the /dev/hidraw on ft260 interfaces when the hid-ft260
driver is loaded.

$ sudo insmod hid-ft260.ko
$ ls /dev/hidraw*
/dev/hidraw0

$ sudo rmmod hid-ft260.ko
$ ls /dev/hidraw*
/dev/hidraw0  /dev/hidraw1  /dev/hidraw2

Reported-by: Enrik Berkhan &lt;Enrik.Berkhan@inka.de&gt;
Signed-off-by: Michael Zaidman &lt;michael.zaidman@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
<entry>
<title>HID: ft260: improve i2c large reads performance</title>
<updated>2022-11-11T10:09:35+00:00</updated>
<author>
<name>Michael Zaidman</name>
<email>michael.zaidman@gmail.com</email>
</author>
<published>2022-11-05T21:11:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=54410c14800ad652c77e5c6fc5c17baad6e42cb6'/>
<id>urn:sha1:54410c14800ad652c77e5c6fc5c17baad6e42cb6</id>
<content type='text'>
The patch increases the read buffer size to 180 bytes. It reduces
the number of ft260_i2c_read() calls by three, improving the big
reads performance.

$ sudo i2ctransfer -y -f 13 w2@0x51 0x0 0x0 r180

Before:

[  +4.071878] ft260_i2c_write_read: off 0x0 rlen 180 wlen 2
[  +0.000005] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0
[  +0.001097] ft260_xfer_status: bus_status 0x41, clock 100
[  +0.000175] ft260_xfer_status: bus_status 0x40, clock 100
[  +0.000004] ft260_i2c_read: rep 0xc2 addr 0x51 len 180 rlen 60 flag 0x3
[  +0.008579] ft260_raw_event: i2c resp: rep 0xde len 60
[  +0.000208] ft260_xfer_status: bus_status 0x40, clock 100
[  +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 120 rlen 60 flag 0x0
[  +0.008794] ft260_raw_event: i2c resp: rep 0xde len 60
[  +0.000181] ft260_xfer_status: bus_status 0x40, clock 100
[  +0.000002] ft260_i2c_read: rep 0xc2 addr 0x51 len 60 rlen 60 flag 0x4
[  +0.008817] ft260_raw_event: i2c resp: rep 0xde len 60
[  +0.000223] ft260_xfer_status: bus_status 0x20, clock 100

After:

[ +11.611642] ft260_i2c_write_read: off 0x0 rlen 180 wlen 2
[  +0.000005] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0
[  +0.008001] ft260_xfer_status: bus_status 0x20, clock 100
[  +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 180 rlen 180 flag 0x7
[  +0.008994] ft260_raw_event: i2c resp: rep 0xde len 60
[  +0.007987] ft260_raw_event: i2c resp: rep 0xde len 60
[  +0.007992] ft260_raw_event: i2c resp: rep 0xde len 60
[  +0.000206] ft260_xfer_status: bus_status 0x20, clock 100

Suggested-by: Enrik Berkhan &lt;Enrik.Berkhan@inka.de&gt;
Signed-off-by: Michael Zaidman &lt;michael.zaidman@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
</feed>
