As reported by syzbot, mcp2221_raw_event lacked
validation of incoming I2C read data sizes, risking buffer
overflows in mcp->rxbuf during multi-part transfers.
As highlighted in the DS20005565B spec, p44, we have:
"The number of read-back data bytes to follow in this packet:
from 0 to a maximum of 60 bytes of read-back bytes."
This patch enforces we don't exceed this limit.

Reported-by: syzbot+52c1a7d3e5b361ccd346@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=52c1a7d3e5b361ccd346
Tested-by: syzbot+52c1a7d3e5b361ccd346@syzkaller.appspotmail.com
Signed-off-by: Arnaud Lecomte <contact@arnaud-lcm.com>
---
 drivers/hid/hid-mcp2221.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index 0f93c22a479f..83941b916cd6 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -814,6 +814,10 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 			}
 			if (data[2] == MCP2221_I2C_READ_COMPL ||
 			    data[2] == MCP2221_I2C_READ_PARTIAL) {
+				if (!mcp->rxbuf || mcp->rxbuf_idx < 0 || data[3] > 60) {
+					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.43.0

Hi Benjamin,
I’m forwarding this patch to you since I noticed that Rishi’s last 
activity on the Linux mailing list was
over three years ago, he may no longer be actively involved.
Please let me know if this is the right approach or if there’s a more 
appropriate way to proceed.
I’d hate to cause any inconvenience.

Cheers,
Arnaud

On 26/07/2025 23:09, Arnaud Lecomte wrote:
> As reported by syzbot, mcp2221_raw_event lacked
> validation of incoming I2C read data sizes, risking buffer
> overflows in mcp->rxbuf during multi-part transfers.
> As highlighted in the DS20005565B spec, p44, we have:
> "The number of read-back data bytes to follow in this packet:
> from 0 to a maximum of 60 bytes of read-back bytes."
> This patch enforces we don't exceed this limit.
>
> Reported-by: syzbot+52c1a7d3e5b361ccd346@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=52c1a7d3e5b361ccd346
> Tested-by: syzbot+52c1a7d3e5b361ccd346@syzkaller.appspotmail.com
> Signed-off-by: Arnaud Lecomte <contact@arnaud-lcm.com>
> ---
>   drivers/hid/hid-mcp2221.c | 4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
> index 0f93c22a479f..83941b916cd6 100644
> --- a/drivers/hid/hid-mcp2221.c
> +++ b/drivers/hid/hid-mcp2221.c
> @@ -814,6 +814,10 @@ static int mcp2221_raw_event(struct hid_device *hdev,
>   			}
>   			if (data[2] == MCP2221_I2C_READ_COMPL ||
>   			    data[2] == MCP2221_I2C_READ_PARTIAL) {
> +				if (!mcp->rxbuf || mcp->rxbuf_idx < 0 || data[3] > 60) {
> +					mcp->status = -EINVAL;
> +					break;
> +				}
>   				buf = mcp->rxbuf;
>   				memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
>   				mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];

On Sat, 26 Jul 2025 23:09:31 +0100, Arnaud Lecomte wrote:
> As reported by syzbot, mcp2221_raw_event lacked
> validation of incoming I2C read data sizes, risking buffer
> overflows in mcp->rxbuf during multi-part transfers.
> As highlighted in the DS20005565B spec, p44, we have:
> "The number of read-back data bytes to follow in this packet:
> from 0 to a maximum of 60 bytes of read-back bytes."
> This patch enforces we don't exceed this limit.
> 
> [...]

Applied to hid/hid.git (for-6.17/upstream-fixes), thanks!

[1/1] hid: fix I2C read buffer overflow in raw_event() for mcp2221
      https://git.kernel.org/hid/hid/c/b56cc41a3ae7

Cheers,
-- 
Benjamin Tissoires <bentiss@kernel.org>