[PATCH AUTOSEL 7.0-5.10] i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl

[PATCH AUTOSEL 7.0-5.10] i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl

[Sasha Levin]

From: Mingyu Wang <25181214217@stu.xidian.edu.cn>

[ Upstream commit 617eb7c0961a8dfcfc811844a6396e406b2923ea ]

While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong
timeout value` warning was observed, accompanied by SMBus controller
state machine corruption.

The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of
10 ms. The user argument is checked against INT_MAX, but it is
subsequently multiplied by 10 before being passed to msecs_to_jiffies().

A malicious user can pass a large value (e.g., 429496729) that passes
the `arg > INT_MAX` check but overflows when multiplied by 10. This
results in a truncated 32-bit unsigned value that bypasses the
internal `(int)m < 0` check in `msecs_to_jiffies()`.

The truncated value is then assigned to `client->adapter->timeout`
(a signed 32-bit int), which is reinterpreted as a negative number.
When passed to wait_for_completion_timeout(), this negative value
undergoes sign extension to a 64-bit unsigned long, triggering the
`schedule_timeout` warning and causing premature returns. This leaves
the SMBus state machine in an unrecoverable state, constituting a
local Denial of Service (DoS).

Fix this by bounding the user argument to `INT_MAX / 10`.

Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
[wsa: move the comment as well]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `i2c: dev`; action verb `prevent`; intent is
to prevent integer overflow in the userspace `I2C_TIMEOUT` ioctl.

Step 1.2 Record: Tags are `Signed-off-by: Mingyu Wang
<25181214217@stu.xidian.edu.cn>` and `Signed-off-by: Wolfram Sang
<wsa+renesas@sang-engineering.com>` with maintainer edit note `[wsa:
move the comment as well]`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Reviewed-by:`, `Link:`, or `Cc: stable` tags were present.

Step 1.3 Record: The body describes a Syzkaller-found `schedule_timeout:
wrong timeout value` warning and SMBus state machine corruption after a
large userspace timeout causes overflow/truncation before storing into
signed `adapter->timeout`. Symptom is local DoS through bad timeout
behavior; root cause is validating `arg` before multiplying by 10.

Step 1.4 Record: This is not hidden cleanup; it is an explicit integer
overflow and local DoS fix.

### Phase 2: Diff Analysis
Step 2.1 Record: One file changed, `drivers/i2c/i2c-dev.c`; committed
diff is 5 insertions and 4 deletions due comment movement. Modified
function: `i2cdev_ioctl()`. Scope: single-file surgical fix.

Step 2.2 Record: Before, `I2C_TIMEOUT` accepted any `arg <= INT_MAX`,
then used `msecs_to_jiffies(arg * 10)`. After, it accepts only `arg <=
INT_MAX / 10`, so the 10 ms unit conversion cannot exceed signed 32-bit
range before assignment to `adapter->timeout`.

Step 2.3 Record: Bug category is integer overflow/truncation and type-
range validation. Broken mechanism: userspace-controlled timeout is
range-checked before scaling, but stored in `struct
i2c_adapter.timeout`, which is `int`.

Step 2.4 Record: Fix quality is high: one validation bound change, no
new API, no refactor. Regression risk is low; it rejects only extreme
timeout values that cannot be represented safely after the documented 10
ms scaling.

### Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the existing `arg > INT_MAX` guard
came from `6ebec961d59b` and the `arg * 10` timeout assignment/comment
came from `cd97f39b7cdf`. `git describe` places them at
`v5.0-rc2~14^2~1` and `v2.6.29-rc7~62^2~2`, respectively.

Step 3.2 Record: No `Fixes:` tag, so no tagged introducing commit to
follow. I still inspected `6ebec961d59b`, which originally fixed
negative retry/timeout values and was itself stable-tagged.

Step 3.3 Record: Recent upstream `drivers/i2c/i2c-dev.c` history shows
this candidate plus unrelated cleanup/fix commits; no prerequisite
series was identified.

Step 3.4 Record: `Mingyu Wang` has this one upstream `drivers/i2c`
commit in the checked history. Wolfram Sang committed it and is the I2C
maintainer in the patch flow.

Step 3.5 Record: No dependent commit found. The patch assumes the long-
existing `I2C_TIMEOUT` case and applies cleanly to the current `v7.0.5`
checkout.

### Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 617eb7c0961a8` found the original submission
at `https://patch.msgid.link/20260427025745.1100768-1-
25181214217@stu.xidian.edu.cn`. `b4 dig -a` found only v1. The submitted
patch was a one-line bound change; the committed version is the
maintainer-adjusted version with comment movement.

Step 4.2 Record: `b4 dig -w` shows recipients: Mingyu Wang, Wolfram
Sang, `linux-i2c@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.

Step 4.3 Record: No `Link:` or `Reported-by:` tag exists. Public web
searches did not find a syzkaller bug page for this exact issue; the
Syzkaller finding is verified only from the commit/patch text.

Step 4.4 Record: No multi-patch series found; standalone patch.

Step 4.5 Record: Stable-list WebFetch was blocked by lore Anubis, and
web search did not find stable-specific discussion. No evidence of
objections or NAKs was found in the b4-fetched mbox.

### Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `i2cdev_ioctl()`.

Step 5.2 Record: Call path is userspace ioctl on `/dev/i2c-*` through
`i2cdev_fops.unlocked_ioctl = i2cdev_ioctl`; compat ioctls fall back to
`i2cdev_ioctl()` for commands not handled specially, including
`I2C_TIMEOUT`.

Step 5.3 Record: Key callee is `msecs_to_jiffies()`, whose runtime
helper treats negative `unsigned int` values as infinite timeout. The
result is assigned to `struct i2c_adapter.timeout`, verified as `int`.

Step 5.4 Record: Buggy path is reachable from userspace with access to
an i2c-dev node. The corrupted timeout is then used by core retry loops
and many bus drivers, including paths using
`wait_for_completion_timeout()`.

Step 5.5 Record: Similar timeout use is widespread in `drivers/i2c`, but
this specific unchecked userspace scaling pattern was found in
`i2c-dev`.

### Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and
`v7.0`; all contain the vulnerable `arg > INT_MAX` plus
`msecs_to_jiffies(arg * 10)` pattern.

Step 6.2 Record: Expected backport difficulty is clean or trivial. `git
apply --check` succeeded on current `v7.0.5`; checked stable snippets
have matching context.

Step 6.3 Record: No alternate stable fix found by subject/phrase
searches in local git history.

### Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is I2C userspace character-device interface,
`drivers/i2c/i2c-dev.c`. Criticality: important, because it exposes bus
control to userspace and affects any system using `i2c-dev`.

Step 7.2 Record: Subsystem is mature but actively maintained. The
affected ioctl path is long-standing.

### Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems exposing `/dev/i2c-*` to
userspace, including embedded, hardware-management, and sensor-control
systems.

Step 8.2 Record: Trigger is setting `I2C_TIMEOUT` to a large value
through ioctl, then using affected I2C/SMBus transfer paths. It requires
access to the device node; no capability check is present in the ioctl
path itself.

Step 8.3 Record: Failure mode is at least a kernel `schedule_timeout:
wrong timeout value` warning and broken timeout behavior; commit text
reports SMBus controller state machine corruption and local DoS.
Severity: HIGH.

Step 8.4 Record: Benefit is high because it blocks a fuzzed, userspace-
reachable DoS class bug in maintained stable trees. Risk is very low
because the patch is one range check in one ioctl case.

### Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: real integer overflow,
Syzkaller-reported in commit text, userspace-reachable with i2c-dev
access, high-severity timeout corruption/DoS, tiny fix, maintainer-
applied, vulnerable code present in checked stable trees, clean apply to
`v7.0.5`. Evidence against: no public syzkaller link, no `Reported-
by`/`Tested-by`, and exact SMBus unrecoverable-state details were not
independently reproduced.

Step 9.2 Record: Stable rules: obviously correct yes; fixes real bug
yes; important issue yes, local DoS/bad kernel timeout path; small and
contained yes; no new features/APIs yes; stable applicability yes for
checked trees.

Step 9.3 Record: No exception category needed; this is a normal bug fix,
not device ID/quirk/DT/build/doc.

Step 9.4 Record: The technical merits strongly support stable
backporting.

## Verification
- Phase 1: Parsed `git show 617eb7c0961a8`; confirmed tags and absence
  of `Fixes:`, `Reported-by:`, `Link:`, and stable tag.
- Phase 2: Inspected committed diff; confirmed one-file change in
  `i2cdev_ioctl()`.
- Phase 3: `git blame` identified `6ebec961d59b` and `cd97f39b7cdf`;
  `git describe` placed them before all checked maintained stable trees.
- Phase 3: `git show 6ebec961d59b` confirmed prior timeout/retry
  negative-value fix and stable nomination.
- Phase 4: `b4 dig`, `b4 dig -a`, `b4 dig -w`, and mbox read found one
  v1 patch, proper I2C recipients, and no visible objections.
- Phase 4: WebFetch of lore was blocked by Anubis; stable-list
  discussion and public syzkaller report remain unverified.
- Phase 5: `rg` and file reads confirmed ioctl file operations, compat
  fallback, `msecs_to_jiffies()`, `adapter->timeout` as `int`, and
  downstream timeout uses.
- Phase 6: Checked `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and `v7.0`
  snippets; all contain the vulnerable pattern.
- Phase 6: `git apply --check` confirmed the upstream diff applies to
  current `v7.0.5`.
- Phase 8: `schedule_timeout()` source confirms negative timeout emits
  `wrong timeout value` and returns 0.

**YES**

 drivers/i2c/i2c-dev.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
index 7bbe0263411eb..ccaac5e29f906 100644
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -487,12 +487,13 @@ static long i2cdev_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 		client->adapter->retries = arg;
 		break;
 	case I2C_TIMEOUT:
-		if (arg > INT_MAX)
+		/*
+		 * For historical reasons, user-space sets the timeout value in
+		 * units of 10 ms.
+		 */
+		if (arg > INT_MAX / 10)
 			return -EINVAL;
 
-		/* For historical reasons, user-space sets the timeout
-		 * value in units of 10 ms.
-		 */
 		client->adapter->timeout = msecs_to_jiffies(arg * 10);
 		break;
 	default:
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] HID: mcp2221: fix OOB write in mcp2221_raw_event()

[Sasha Levin]

From: Florian Pradines <florian.pradines@gmail.com>

[ Upstream commit f097d246677b03db814c5862f368cea341b76a00 ]

mcp2221_raw_event() copies device-supplied data into mcp->rxbuf at
offset rxbuf_idx without checking that the copy fits within the
destination buffer. A device responding with up to 60 bytes to a
small I2C/SMBus read can overflow the buffer.

Add a rxbuf_size field to struct mcp2221, set it alongside rxbuf in
mcp_i2c_smbus_read(), and check rxbuf_idx + data[3] <= rxbuf_size
before the memcpy.

Reported-by: Benoît Sevens <bsevens@google.com>
Signed-off-by: Florian Pradines <florian.pradines@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `HID: mcp2221`; action verb `fix`; claimed
intent: prevent an out-of-bounds write in `mcp2221_raw_event()` when
copying device-supplied I2C read data into `mcp->rxbuf`.

Step 1.2 Record: tags found in upstream commit
`f097d246677b03db814c5862f368cea341b76a00`: `Reported-by: Benoît Sevens
<bsevens@google.com>`, `Signed-off-by: Florian Pradines
<florian.pradines@gmail.com>`, `Signed-off-by: Jiri Kosina
<jkosina@suse.com>`. No `Fixes:`, no `Cc: stable`, no `Link:` in the
commit message.

Step 1.3 Record: bug description is explicit: `mcp2221_raw_event()`
copies `data[3]` bytes into `mcp->rxbuf + rxbuf_idx` without checking
the destination buffer size. Failure mode is kernel memory corruption
via OOB write when a device returns up to 60 bytes for a smaller
requested read.

Step 1.4 Record: not hidden; this is a direct memory-safety fix.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed, `drivers/hid/hid-mcp2221.c`, 7
insertions. Modified areas: `struct mcp2221`, `mcp_i2c_smbus_read()`,
`mcp2221_raw_event()`. Scope: single-file surgical fix.

Step 2.2 Record: before, the driver tracked `rxbuf` and `rxbuf_idx` but
not the destination size. After, it stores `rxbuf_size` when setting
`rxbuf`, and rejects `rxbuf_idx + data[3] > rxbuf_size` before
`memcpy()`.

Step 2.3 Record: bug category is memory safety, specifically OOB write
from device-controlled length and cumulative receive offset. The earlier
`data[3] > 60` check only capped a single MCP2221 report, not the
destination buffer size.

Step 2.4 Record: fix is minimal and locally correct for the upstream
parent, but direct stable backports need care because older stable
branches still have two manual `mcp_smbus_xfer()` paths that set
`mcp->rxbuf` directly.

## Phase 3: Git History
Step 3.1 Record: `git blame` showed `rxbuf`, `rxbuf_idx`,
`mcp_i2c_smbus_read()`, and the `memcpy()` path originated in
`67a95c21463d0`, first contained in `v5.7-rc1`. The partial-read
handling came from `2682468671aa0`, first contained in `v6.8-rc1`. The
prior per-report `data[3] > 60` guard came from `b56cc41a3ae73`, first
contained in `v6.17-rc4` and backported to stable equivalents.

Step 3.2 Record: no `Fixes:` tag, so no tagged introducing commit to
follow.

Step 3.3 Record: recent related commits include `b56cc41a3ae73` for the
60-byte report cap, `e31b556c0ba21` for read-error cancellation, and
`ab05515757fcb` for using `mcp_i2c_smbus_read()` for block reads.
`ab05515757fcb` is an important context dependency for the exact
upstream diff.

Step 3.4 Record: author Florian Pradines had no other local commits
found in `drivers/hid`; Jiri Kosina, the HID maintainer,
committed/applied the patch.

Step 3.5 Record: upstream parent contains `ab05515757fcb`; stable
branches checked from `5.10.y` through `7.0.y` do not. A stable backport
should either adapt the patch to set `rxbuf_size` in the two remaining
manual `mcp_smbus_xfer()` paths or include an appropriate
prerequisite/backport.

## Phase 4: Mailing List / External Research
Step 4.1 Record: `b4 dig -c f097d246677b03db814c5862f368cea341b76a00`
found the lore thread: `https://patch.msgid.link/20260509094517.2691246-
1-florian.pradines@gmail.com`. `b4 dig -a` showed only v1.

Step 4.2 Record: `b4 dig -w` showed recipients included Florian
Pradines, Rishi Gupta, Jiri Kosina, Benjamin Tissoires, `linux-i2c`, and
`linux-input`.

Step 4.3 Record: reporter Benoît Sevens previously submitted a similar
heap-buffer-overflow patch. Jiri replied that Benoît’s patch was mangled
and that Florian’s patch would be taken with Benoît added as `Reported-
by`. Benoît then noted the missing `mcp_smbus_xfer()` assignments, which
is relevant for older stable bases.

Step 4.4 Record: not part of a multi-patch series. Related patches exist
for report-size validation, but Jiri questioned the “MCP2221 always
sends 64-byte reports” assumption in that separate thread.

Step 4.5 Record: direct lore/stable WebFetch was blocked by Anubis, but
web search found related stable discussion for prior mcp2221 fixes, not
an exact stable request for `f097d246677b`.

## Phase 5: Semantic Analysis
Step 5.1 Record: changed function is `mcp_i2c_smbus_read()`; changed
callback is `mcp2221_raw_event()`.

Step 5.2 Record: callers of `mcp_i2c_smbus_read()` are `mcp_i2c_xfer()`
and `mcp_smbus_xfer()`, wired into `mcp_i2c_algo`. `mcp2221_raw_event()`
is called from HID core before normal raw report processing, via
`hid_input_report()` / `__hid_input_report()`.

Step 5.3 Record: affected callees include `mcp_send_data_req_status()`,
`mcp_send_report()`, `wait_for_completion_timeout()`, and the vulnerable
`memcpy()`.

Step 5.4 Record: reachability is real: USB HID interrupt input reaches
`mcp2221_raw_event()`, and I2C/SMBus transfers reach
`mcp_i2c_smbus_read()` through the registered I2C adapter.
Triggerability by an unprivileged local user was not verified; trigger
by a malicious or buggy MCP2221-side device response is verified by the
code path.

Step 5.5 Record: similar pattern found in stable branches: two manual
`mcp_smbus_xfer()` receive-buffer assignments remain in stable branches
and must be handled in backports.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: the driver was introduced in `v5.7-rc1`; local stable
refs `5.10.y`, `5.15.y`, `6.1.y`, `6.6.y`, `6.12.y`, `6.18.y`, `6.19.y`,
and `7.0.y` contain the vulnerable `rxbuf`/`memcpy()` pattern. `5.4.y`
does not contain the driver.

Step 6.2 Record: `git apply --check` against current
`stable/linux-7.0.y` succeeds syntactically, but semantic backport work
is needed because stable lacks `ab05515757fcb`.

Step 6.3 Record: prior stable branches already contain the earlier
60-byte cap fix or its backported equivalent, but that does not fix
cumulative overflow into smaller destination buffers.

## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is HID driver for the Microchip MCP2221 USB-
to-I2C/SMBus bridge. Criticality: driver-specific, but memory corruption
from USB/HID device input is high severity for affected systems.

Step 7.2 Record: file history shows active recent maintenance and
multiple security/correctness fixes in this driver.

## Phase 8: Impact And Risk
Step 8.1 Record: affected population is users of MCP2221 hardware or
systems exposed to such USB HID devices.

Step 8.2 Record: trigger is an I2C/SMBus read where the MCP2221-side
response reports more bytes than the destination buffer can hold.
Physical/malicious-device trigger is verified; unprivileged local
trigger depends on device-node permissions and was not verified.

Step 8.3 Record: failure mode is OOB write into kernel memory, severity
HIGH to CRITICAL due to memory corruption/crash/security risk.

Step 8.4 Record: benefit is high. Risk is low for the upstream parent
and for correctly adapted stable backports. Risk is medium for blind
cherry-picks into older stable branches because `rxbuf_size` would not
be set in all stable receive-buffer paths.

## Phase 9: Final Synthesis
Evidence for backporting: real OOB write, explicit reporter, small
patch, maintainer-applied, affects stable-supported code since `5.10.y`,
fixes a memory-corruption class bug.

Evidence against or concerns: no `Fixes:`/`Cc: stable`; exact upstream
diff assumes `ab05515757fcb`, absent from checked stable branches; blind
cherry-pick is not sufficient for older stable trees.

Stable rules checklist: obviously correct on its upstream base: yes.
Fixes a real user-affecting bug: yes. Important issue: yes, kernel
memory corruption. Small and contained: yes, 7 insertions. No new
feature/API: yes. Applies to stable: syntactically yes on `7.0.y`, but
older stable needs a branch-specific backport adjustment.

Exception category: none; this is a memory-safety fix, not a device
ID/quirk/doc/build exception.

## Verification
- Phase 1: fetched and inspected upstream commit
  `f097d246677b03db814c5862f368cea341b76a00`.
- Phase 2: verified exact diff is 7 insertions in `drivers/hid/hid-
  mcp2221.c`.
- Phase 3: ran `git blame`, `git describe --contains`, and targeted `git
  log` without `--all`; identified `67a95c21463d0`, `2682468671aa0`,
  `b56cc41a3ae73`, and `ab05515757fcb`.
- Phase 4: ran `b4 dig -c`, `b4 dig -a`, `b4 dig -w`, and fetched mboxes
  with `b4 mbox`; verified Jiri’s “Applied, thanks” and Benoît’s earlier
  report/backport-relevant concern.
- Phase 5: used code search and file reads to verify HID and I2C/SMBus
  call paths.
- Phase 6: used `git grep` against stable refs to verify vulnerable
  patterns in `5.10.y` through `7.0.y`, and absence from `5.4.y`.
- Phase 6: verified exact patch syntactically applies to current
  `stable/linux-7.0.y`, but `ab05515757fcb` is not an ancestor of
  checked stable refs.
- Phase 8: severity is based on verified device-controlled `memcpy()`
  into kernel buffer without destination-size check.
- UNVERIFIED: no runtime reproducer was executed; no build test was run;
  unprivileged local triggerability was not verified.

This should be backported, but stable maintainers should not blindly
cherry-pick it into pre-`ab05515757fcb` trees without adding
`rxbuf_size` initialization to every remaining `mcp->rxbuf` assignment.

**YES**

 drivers/hid/hid-mcp2221.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index ef3b5c77c38e3..badd4958bc12c 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -121,6 +121,7 @@ struct mcp2221 {
 	u8 *rxbuf;
 	u8 txbuf[64];
 	int rxbuf_idx;
+	int rxbuf_size;
 	int status;
 	u8 cur_i2c_clk_div;
 	struct gpio_chip *gc;
@@ -323,12 +324,14 @@ static int mcp_i2c_smbus_read(struct mcp2221 *mcp,
 		mcp->txbuf[3] = (u8)(msg->addr << 1);
 		total_len = msg->len;
 		mcp->rxbuf = msg->buf;
+		mcp->rxbuf_size = msg->len;
 	} else {
 		mcp->txbuf[1] = smbus_len;
 		mcp->txbuf[2] = 0;
 		mcp->txbuf[3] = (u8)(smbus_addr << 1);
 		total_len = smbus_len;
 		mcp->rxbuf = smbus_buf;
+		mcp->rxbuf_size = smbus_len;
 	}
 
 	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 4);
@@ -912,6 +915,10 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 					mcp->status = -EINVAL;
 					break;
 				}
+				if (mcp->rxbuf_idx + data[3] > mcp->rxbuf_size) {
+					mcp->status = -EINVAL;
+					break;
+				}
 				buf = mcp->rxbuf;
 				memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
 				mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] HID: ft260: validate i2c input report length

[Sasha Levin]

From: Michael Zaidman <michael.zaidman@gmail.com>

[ Upstream commit 80c4bbb2b38513e9c3d84805fa61a0ee16d79c45 ]

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->length on a
1-byte report is an OOB read.

Second, validate xfer->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 <sebasjosue84@gmail.com>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
This should be backported. It is a small, single-driver HID fix for a
real out-of-bounds read in `ft260_raw_event()`, reachable from FT260 USB
HID input reports before HID core report-size validation runs. The
benefit is high because the failure mode is memory-safety/security
relevant; the regression risk is low because valid reports are unchanged
and only malformed reports are rejected.

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record: subsystem `HID: ft260`; action verb `validate`; intent is to
validate I2C input report length.

Record: tags in commit `80c4bbb2b38513e9c3d84805fa61a0ee16d79c45`:
`Reported-by: Sebastián Josué Alba Vives <sebasjosue84@gmail.com>`,
`Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>`, `Signed-
off-by: Jiri Kosina <jkosina@suse.com>`. No `Fixes:`, `Link:`, `Cc:
stable`, `Tested-by`, `Reviewed-by`, or `Acked-by` in the committed
message.

Record: bug description is explicit: malicious or malfunctioning
FT260-compatible HID devices can send too-short reports or corrupted
length fields, causing OOB reads. Symptom/failure mode is OOB heap read
before/inside `memcpy()`. No affected version listed in commit body.

Record: this is not a hidden fix; it is directly described as a memory-
safety fix.

### Phase 2: Diff Analysis
Record: one file changed, `drivers/hid/hid-ft260.c`, `14` insertions and
`2` deletions. Only `ft260_raw_event()` is modified. Scope is single-
file surgical.

Record: before, `ft260_raw_event()` cast `data` to `struct
ft260_i2c_input_report` and accessed `xfer->report`/`xfer->length`
without checking `size`; then `memcpy()` used `xfer->length` after
checking only destination capacity. After, it rejects reports shorter
than the 2-byte header and rejects `xfer->length > size - offsetof(...,
data)` before copying.

Record: bug category is memory safety: OOB read on truncated input and
OOB source read on corrupted length. No locking, API, or feature
behavior changes.

Record: fix quality is strong: minimal, obvious bounds checks
immediately before the unsafe accesses/copy. Regression risk is low;
only malformed reports are rejected. The use of actual `size` avoids the
earlier reviewed problem of rejecting valid short FT260 report IDs.

### Phase 3: Git History Investigation
Record: `git blame` shows the vulnerable header access and `memcpy()`
came from `6a82582d9fa4` (`HID: ft260: add usb hid to i2c host bridge
driver`, first contained around `v5.13-rc1`). The destination-buffer
check came from `b7121e3c04440` (`HID: ft260: skip unexpected HID input
reports`, first contained around `v6.2-rc1`).

Record: no `Fixes:` tag, so Step 3.2 is not applicable.

Record: recent file history shows related FT260 fixes and enhancements,
including `b7121e3c04440`, but no prerequisite needed for the new
source-length/header validation. For older `5.15.y`/`6.1.y`, the exact
patch context does not apply because `b7121e3c04440` is absent, but the
fix itself is still conceptually standalone.

Record: author Michael Zaidman is listed in `MAINTAINERS` as FT260
maintainer and has a long FT260 commit history. Jiri Kosina committed
the patch and is listed as HID core maintainer.

### Phase 4: Mailing List And External Research
Record: `b4 dig -c 80c4bbb2b3851` found the matching submission at `http
s://patch.msgid.link/20260411062437.279838-1-michael.zaidman@gmail.com`.

Record: `b4 dig -a` showed prior versions/discussion. The original
reporter’s v1/v2 were Cc’d to stable and had a too-broad `size < 64`
approach. Review identified that valid FT260 reports can be shorter,
leading to Michael’s final per-driver fix using the header size and
actual report size.

Record: `b4 dig -w` showed Michael Zaidman, Jiri Kosina, Benjamin
Tissoires, linux-input, linux-kernel, and the reporter on the final
submission.

Record: saved lore mbox shows Jiri applied the final patch to
`hid.git#for-7.1/upstream-fixes`. The thread also contains Michael’s
hardware test note: tested on FT260 with I2C-attached EEPROM behind
PCA9548 muxes, including small and larger reads.

Record: stable-specific history exists in the earlier reporter
submissions, including `Cc: stable@vger.kernel.org` and explicit
OOB/security rationale. No NAK remained against the final version.

### Phase 5: Code Semantic Analysis
Record: modified function is `ft260_raw_event()`.

Record: callers traced manually: `ft260_raw_event()` is registered as
`.raw_event`; HID core calls `hdrv->raw_event()` in
`__hid_input_report()` before `hid_report_raw_event()` performs report-
size checks. USB HID paths call `hid_input_report()` from
interrupt/control completion paths.

Record: callees/side effects: `ft260_raw_event()` copies HID I2C
response payload into `dev->read_buf`, advances `read_idx`, and
completes the waiting I2C read when enough data arrives.

Record: reachability: normal FT260 I2C reads go through `i2c_adapter`
operations (`ft260_i2c_xfer()` / `ft260_smbus_xfer()` ->
`ft260_i2c_read()`), while the malformed input itself is supplied by the
USB HID device. Userspace reachability depends on system I2C access
permissions; unprivileged trigger was not verified.

Record: similar pattern in this function is unique for the FT260 I2C
input report copy. Related HID OOB fixes exist in recent HID history,
supporting the general risk class but not required for this patch.

### Phase 6: Stable Tree Analysis
Record: `drivers/hid/hid-ft260.c` exists in `stable/linux-5.15.y`,
`6.1.y`, `6.6.y`, `6.12.y`, and current `v7.0.9` checkout; it does not
exist in `4.19.y`, `5.4.y`, or `5.10.y`.

Record: the buggy code pattern exists in `5.15.y`, `6.1.y`, `6.6.y`, and
`6.12.y`; none contain `80c4bbb2b3851`.

Record: patch applies cleanly to `6.6.y`, `6.12.y`, and current `v7.0.9`
using a temporary index. It does not apply unchanged to `5.15.y` or
`6.1.y` because those lack `b7121e3c04440` context, so older branches
need a small manual backport.

Record: no alternate stable fix for this exact validation was found.

### Phase 7: Subsystem And Maintainer Context
Record: subsystem is HID driver for an FTDI USB HID-to-I2C bridge.
Criticality is driver-specific but security-relevant for systems using
that hardware or exposed USB ports.

Record: subsystem/file activity is active; recent HID history includes
several OOB fixes, and FT260 has ongoing maintenance by Michael Zaidman.

### Phase 8: Impact And Risk
Record: affected population is driver/config/hardware-specific: systems
with `CONFIG_HID_FT260` and FT260 or malicious FT260-emulating USB HID
devices.

Record: trigger is a malformed HID input report from the device,
especially during/around I2C read handling. Physical or device-level
control is required; unprivileged local trigger was not verified.

Record: failure mode is OOB heap read, with reporter discussion noting
possible data exposure through the I2C read buffer. Severity: HIGH,
security-relevant memory safety.

Record: benefit is high for affected systems; risk is low because the
patch is small, contained, and only rejects malformed reports.

### Phase 9: Final Synthesis
Evidence for backporting: real OOB read; malicious/malfunctioning device
trigger; HID raw_event is called before HID core size validation;
maintainer-authored final fix; hardware test notes; one function and one
file; no new API or feature; applies cleanly to current 7.0 and newer
stable branches.

Evidence against/backport concerns: older `5.15.y` and `6.1.y` need
manual context adjustment; `4.19.y`, `5.4.y`, and `5.10.y` lack the
driver. No `Fixes:` tag, but that is not a negative signal here.

Stable rules checklist: obviously correct and tested: yes, by code
inspection and submission test notes. Fixes a real bug: yes, OOB reads.
Important issue: yes, memory safety/security. Small and contained: yes,
`14+/2-` in one function. No new features/APIs: yes. Can apply to
stable: yes for 6.6/6.12/7.0; minor backport needed for 5.15/6.1.

Exception categories: none; this is a direct memory-safety bug fix, not
a device ID/quirk/build/doc exception.

## Verification
- [Phase 1] `git show --format=fuller --no-patch 80c4bbb2b3851`:
  confirmed subject, message, author/committer, and tags.
- [Phase 2] `git show --function-context 80c4bbb2b3851 --
  drivers/hid/hid-ft260.c`: confirmed only `ft260_raw_event()` changes
  and exact bounds checks.
- [Phase 3] `git blame -L 1065,1085 80c4bbb2b3851^ -- drivers/hid/hid-
  ft260.c`: confirmed vulnerable lines originated in `6a82582d9fa4` and
  related destination check in `b7121e3c04440`.
- [Phase 3] `git show` on `6a82582d9fa4` and `b7121e3c04440`: confirmed
  driver introduction and related unexpected-report fix.
- [Phase 4] `b4 dig -c`, `-a`, `-w`, and `-m`: found final lore thread,
  revisions, recipients, maintainer apply message, and test notes.
- [Phase 4] WebFetch/Spinics: confirmed earlier stable-cc’d reporter
  patches and review discussion about avoiding a blanket 64-byte check.
- [Phase 5] Read `drivers/hid/hid-core.c`: confirmed `raw_event` runs
  before `hid_report_raw_event()` size validation.
- [Phase 5] Searched FT260 call paths: confirmed registration as
  `.raw_event`, USB HID input path, and I2C adapter read paths.
- [Phase 6] `git ls-tree` and `git grep` against stable branches:
  confirmed affected code exists in `5.15.y+` branches checked, absent
  from older listed branches.
- [Phase 6] Temporary-index `git apply --check`: clean for `6.6.y`,
  `6.12.y`, and current `v7.0.9`; fails unchanged for `5.15.y`/`6.1.y`,
  requiring minor backport.
- [Phase 7] `MAINTAINERS` search: confirmed Michael Zaidman maintains
  FT260 and Jiri/Benjamin maintain HID core.
- UNVERIFIED: whether an unprivileged local user can trigger this on a
  given distro; that depends on USB access, I2C device permissions, and
  deployment policy.

**YES**

 drivers/hid/hid-ft260.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
index 333341e80b0ec..70e2eedb465af 100644
--- a/drivers/hid/hid-ft260.c
+++ b/drivers/hid/hid-ft260.c
@@ -1068,10 +1068,22 @@ static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,
 	struct ft260_device *dev = hid_get_drvdata(hdev);
 	struct ft260_i2c_input_report *xfer = (void *)data;
 
+	if (size < offsetof(struct ft260_i2c_input_report, data)) {
+		hid_err(hdev, "short report %d\n", size);
+		return -1;
+	}
+
 	if (xfer->report >= FT260_I2C_REPORT_MIN &&
 	    xfer->report <= FT260_I2C_REPORT_MAX) {
-		ft260_dbg("i2c resp: rep %#02x len %d\n", xfer->report,
-			  xfer->length);
+		ft260_dbg("i2c resp: rep %#02x len %d size %d\n",
+			  xfer->report, xfer->length, size);
+
+		if (xfer->length > size -
+		    offsetof(struct ft260_i2c_input_report, data)) {
+			hid_err(hdev, "report %#02x: length %d exceeds HID report size\n",
+				xfer->report, xfer->length);
+			return -1;
+		}
 
 		if ((dev->read_buf == NULL) ||
 		    (xfer->length > dev->read_len - dev->read_idx)) {
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] i2c: acpi: Add ELAN0678 to i2c_acpi_force_100khz_device_ids

[Sasha Levin]

From: Niels Franke <nielsfranke@gmail.com>

[ Upstream commit 9998e388be9930c106eb5904c23ecf2162407527 ]

The ELAN0678 touchpad (04F3:3195) found in the Lenovo ThinkPad X13
exhibits excessive smoothing when the I2C bus runs at 400KHz, making
the touchpad feel sluggish when plugged into AC power. This is the
same issue previously fixed for ELAN06FA.

The device's ACPI table (Lenovo TP-R22) specifies 0x00061A80 (400KHz)
for the I2cSerialBusV2 descriptor. Forcing the bus to 100KHz eliminates
the sluggish behavior.

Signed-off-by: Niels Franke <nielsfranke@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[wsa: kept the sorting]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

Step 1.1 - Subject:
Record: Subsystem `i2c: acpi`; action verb `Add`; intent is to add ACPI
HID `ELAN0678` to the existing 100 kHz forced-speed quirk table.

Step 1.2 - Tags:
Record: `Signed-off-by: Niels Franke <nielsfranke@gmail.com>`; `Acked-
by: Mika Westerberg <mika.westerberg@linux.intel.com>`; maintainer note
`[wsa: kept the sorting]`; `Signed-off-by: Wolfram Sang
<wsa+renesas@sang-engineering.com>`. No `Fixes:`, `Reported-by:`,
`Tested-by:`, `Link:`, or `Cc: stable@vger.kernel.org` tags.

Step 1.3 - Body:
Record: The bug is real hardware misbehavior: ELAN0678 touchpad
`04F3:3195` on Lenovo ThinkPad X13 becomes sluggish/excessively smoothed
when ACPI-described I2C speed is 400 kHz. The commit says forcing 100
kHz eliminates it. Root cause is a bad/not-working speed choice for this
device, matching the earlier ELAN06FA workaround.

Step 1.4 - Hidden bug fix:
Record: Yes. Although phrased as “Add”, this is a hardware
workaround/quirk for a user-visible input-device malfunction, not new
feature work.

## Phase 2: Diff Analysis

Step 2.1 - Inventory:
Record: One file changed: `drivers/i2c/i2c-core-acpi.c`, `+1/-0`. It
adds `{ "ELAN0678", 0 }` to `i2c_acpi_force_100khz_device_ids`. Scope is
a single-file, one-line hardware quirk.

Step 2.2 - Code flow:
Record: Before, ELAN0678 used the normal ACPI/min-speed path and could
run at the 400 kHz speed from firmware. After, when
`i2c_acpi_lookup_speed()` sees an ACPI device matching `ELAN0678`, it
sets `lookup->force_speed = I2C_MAX_STANDARD_MODE_FREQ`, causing
`i2c_acpi_find_bus_speed()` to return 100 kHz.

Step 2.3 - Bug mechanism:
Record: Hardware workaround. The broken condition is a known-not-working
I2C bus speed for a specific ACPI HID. The fix reuses the existing
forced-100-kHz mechanism.

Step 2.4 - Fix quality:
Record: Obviously correct and minimal. It only affects machines exposing
ACPI HID `ELAN0678`. Regression risk is very low: affected devices will
run slower I2C, intentionally matching the verified workaround; all
other devices are unchanged.

## Phase 3: Git History

Step 3.1 - Blame:
Record: `git blame` on `origin/master` shows the new line is commit
`9998e388be993`; the 100 kHz table and `ELAN06FA` handling came from
`bfd74cd1fbc026`, first contained around `v6.14-rc1`; `DLL0945` came
from `0b7c9528facdb5`, first contained around `v6.17-rc1`.

Step 3.2 - Fixes tag:
Record: Not applicable; no `Fixes:` tag is present.

Step 3.3 - File history:
Record: Recent file history shows related quirks `ELAN06FA` and
`DLL0945`, plus unrelated treewide allocation conversions. No
prerequisite structural change is needed where the 100 kHz table already
exists.

Step 3.4 - Author context:
Record: Local history shows Niels Franke has this one I2C commit on
`origin/master`. The patch was acked by Mika Westerberg, listed in
`MAINTAINERS` as I2C ACPI maintainer, and committed by Wolfram Sang.

Step 3.5 - Dependencies:
Record: Standalone for stable branches that already have
`i2c_acpi_force_100khz_device_ids`. For branches lacking the table, it
depends on the earlier ELAN06FA forced-100-kHz infrastructure.

## Phase 4: Mailing List And External Research

Step 4.1 - Original discussion:
Record: `b4 dig -c 9998e388be993` found the original submission at
`https://patch.msgid.link/20260418053719.15766-1-nielsfranke@gmail.com`.
The mirror thread shows v1 only, Mika Westerberg acked it, and Wolfram
Sang applied it to `for-current` while keeping sort order. No objections
or NAKs found.

Step 4.2 - Reviewers/recipients:
Record: `b4 dig -w` shows recipients included Niels Franke,
`westeri@kernel.org`, Wolfram Sang, `linux-i2c`, `linux-acpi`, and
`linux-kernel`. This reached the relevant I2C ACPI maintainer and lists.

Step 4.3 - Bug report:
Record: No separate `Reported-by` or bug tracker link in the commit. The
commit message itself documents affected hardware, ACPI table speed, and
the tested workaround. Web search also found unrelated ELAN0678 user
reports, but I did not rely on those for the final decision.

Step 4.4 - Series context:
Record: `b4 dig -a` shows a single v1 patch, not a multi-patch series.

Step 4.5 - Stable discussion:
Record: Direct lore stable fetch was blocked by Anubis; web search found
no specific stable-list discussion for ELAN0678. Stable branch git logs
sampled do not yet contain ELAN0678.

## Phase 5: Code Semantic Analysis

Step 5.1 - Key functions:
Record: The diff changes only the ACPI ID table, but behavior flows
through `i2c_acpi_lookup_speed()` and `i2c_acpi_find_bus_speed()`.

Step 5.2 - Callers:
Record: `i2c_acpi_find_bus_speed()` is called by multiple I2C bus
drivers, including DesignWare, USBIO, SynQuacer, LS2X, Zhaoxin, and AMD
MP2. For DesignWare, `dw_i2c_plat_probe()` and PCI probe paths call
`i2c_dw_fw_parse_and_configure()`, which calls the ACPI speed lookup
during controller setup.

Step 5.3 - Callees:
Record: The relevant code calls `acpi_walk_namespace()`,
`i2c_acpi_do_lookup()`, and `acpi_match_device_ids()`; if matched, it
returns the forced speed to bus-driver timing configuration.

Step 5.4 - Reachability:
Record: Reachable during I2C adapter/controller initialization on ACPI
systems. On affected Lenovo hardware, this path controls the bus speed
used for the touchpad.

Step 5.5 - Similar patterns:
Record: Verified sibling quirks `ELAN06FA` and `DLL0945` in the same
table, both addressing touchpad sluggishness at higher I2C speed.

## Phase 6: Stable Tree Analysis

Step 6.1 - Buggy code in stable:
Record: Sampled stable branches `5.10.y`, `5.15.y`, `6.6.y`, `6.12.y`,
`6.15.y` through `7.0.y` already contain the 100 kHz quirk table with
`ELAN06FA`/`DLL0945`, but not `ELAN0678`. `5.4.y` has ACPI speed lookup
but not the forced-100-kHz table in the sampled state.

Step 6.2 - Backport difficulty:
Record: Clean or trivial for branches with both `DLL0945` and `ELAN06FA`
adjacent. Branches lacking `DLL0945` or the table may need a trivial
context adjustment or dependency backport.

Step 6.3 - Related fixes already stable:
Record: Stable branches sampled already carry related ELAN06FA/DLL0945
quirks, but no ELAN0678 equivalent.

## Phase 7: Subsystem Context

Step 7.1 - Subsystem:
Record: `drivers/i2c/i2c-core-acpi.c`, I2C ACPI support. Criticality is
important for affected ACPI laptop hardware, but not universal/core.

Step 7.2 - Activity:
Record: File history shows active maintenance and recent hardware quirk
additions. The patch was accepted through the I2C maintainer path.

## Phase 8: Impact And Risk

Step 8.1 - Affected users:
Record: Users of systems exposing the ELAN0678 ACPI touchpad,
specifically verified by commit message for Lenovo ThinkPad X13.

Step 8.2 - Trigger:
Record: Triggered when the I2C bus is configured at 400 kHz for this
device, including via the Lenovo TP-R22 ACPI `I2cSerialBusV2`
descriptor. This is normal boot/device setup, not an obscure manual
path.

Step 8.3 - Severity:
Record: Medium severity user-visible hardware malfunction: sluggish
touchpad/input behavior. Not a crash, security issue, or data
corruption.

Step 8.4 - Risk-benefit:
Record: Benefit is high for affected laptops because it restores usable
touchpad behavior. Risk is very low because it is a one-line ACPI HID-
specific quirk using existing logic.

## Phase 9: Final Synthesis

Step 9.1 - Evidence:
Record: For backporting: real hardware bug, existing quirk mechanism,
one-line scoped change, maintainer ack, accepted by I2C maintainer,
stable branches already carry analogous quirks. Against backporting: no
explicit stable tag, no separate bug report link, not a critical
crash/security fix. Unresolved: exact applicability to every older
stable branch; `5.4.y` would need more than this one-line context.

Step 9.2 - Stable rules:
Record: Obviously correct: yes. Tested: commit states forcing 100 kHz
eliminates the issue, though no `Tested-by` tag. Real bug: yes, touchpad
sluggishness. Important enough: yes under hardware quirk/workaround
practice. Small/contained: yes, one line. No new APIs/features: yes.
Applies to stable: yes for branches with the existing table; trivial
adjustment/dependency for older divergent branches.

Step 9.3 - Exception:
Record: This falls squarely under the stable hardware quirk/workaround
exception.

Step 9.4 - Decision:
Record: Backport. The risk is tiny and the fix is exactly the sort of
targeted hardware workaround stable trees routinely carry.

## Verification

- Phase 1: Parsed `git show --format=fuller --stat --patch
  9998e388be993`; confirmed subject, body, tags, and one-line diff.
- Phase 2: Read `drivers/i2c/i2c-core-acpi.c`; confirmed
  `i2c_acpi_force_100khz_device_ids` is checked by
  `i2c_acpi_lookup_speed()` and returns 100 kHz through
  `i2c_acpi_find_bus_speed()`.
- Phase 3: Ran `git blame` on the relevant lines; confirmed commits for
  `ELAN06FA`, `DLL0945`, and `ELAN0678`.
- Phase 3: Ran `git describe --contains`; confirmed first-containing
  release positions for related mainline commits.
- Phase 4: Ran `b4 dig -c`, `b4 dig -a`, and `b4 dig -w`; found original
  v1 submission, no later revisions, and relevant recipients.
- Phase 4: Fetched the public mirror thread; confirmed Mika Westerberg’s
  ack and Wolfram Sang’s application note.
- Phase 5: Used semantic search, `rg`, and file reads; confirmed
  DesignWare and other I2C bus drivers call `i2c_acpi_find_bus_speed()`.
- Phase 6: Used `git grep` and stable branch logs; confirmed sampled
  stable branches contain related forced-speed quirks but not ELAN0678.
- Phase 8: Failure mode is verified from the commit message and lore
  thread: sluggish/excessively smoothed touchpad at 400 kHz, fixed by
  100 kHz.
- UNVERIFIED: Direct `lore.kernel.org/stable` content was blocked by
  Anubis, so I could not independently inspect stable-list discussion
  there.

**YES**

 drivers/i2c/i2c-core-acpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index 2cbd31f77667a..28c0e4884a7f2 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -371,6 +371,7 @@ static const struct acpi_device_id i2c_acpi_force_100khz_device_ids[] = {
 	 * a 400KHz frequency. The root cause of the issue is not known.
 	 */
 	{ "DLL0945", 0 },
+	{ "ELAN0678", 0 },
 	{ "ELAN06FA", 0 },
 	{}
 };
-- 
2.53.0