Re: [RFC PATCH] HID: mcp2221: bound I2C readback copies to the receive buffer

Re: [RFC PATCH] HID: mcp2221: bound I2C readback copies to the receive buffer

[gregkh]

On Fri, May 08, 2026 at 12:45:44PM +0000, nsa@linux.do wrote:
> The MCP2221 I2C readback path copies data[3] bytes from the incoming HID
> report into mcp->rxbuf at mcp->rxbuf_idx:
> 
>       memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
> 
> The current checks only reject a NULL rxbuf, a negative rxbuf_idx, and
> chunks larger than 60 bytes. They do not verify that the reported chunk
> still fits in the destination buffer for the current transaction.
> 
> As a result, a device response can claim a chunk length that exceeds the
> remaining space in the caller-provided receive buffer. For example, a
> 1-byte read request may still return data[3] == 60, which would cause a
> write past the end of the target buffer in the unpatched code.
> 
> Track the receive buffer length for the active transaction and reject
> MCP2221_I2C_GET_DATA responses whose chunk would exceed the remaining
> space.bang
> 
> This seems security-relevant to me, similar in kind to CVE-2022-50131,
> although it affects a different path.
> 
> I also validated this change on a Raspberry Pi system with an actual
> MCP2221 device attached, where the oversized readback chunks were rejected
> and the original out-of-bounds write path was no longer reached.
> 
> I am primarily approaching this from the vulnerability research side, so I
> would appreciate maintainer review on the overall fix quality and whether
> this is the preferred way to address it.
> 
> Signed-off-by: Lexpl0it<nsa@linux.do>bi

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch is malformed (tabs converted to spaces, linewrapped, etc.)
  and can not be applied.  Please read the file,
  Documentation/process/email-clients.rst in order to fix this.

- It looks like you did not use your "real" name for the patch on either
  the Signed-off-by: line, or the From: line (both of which have to
  match).  Please read the kernel file,
  Documentation/process/submitting-patches.rst for how to do this
  correctly.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot