Linux Input/HID development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [PATCH 08/11] Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging
Date: Sat, 23 May 2026 05:39:26 +0000	[thread overview]
Message-ID: <20260523053927.3FAE11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260523050634.501509-8-dmitry.torokhov@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The coherent DMA memory for the IN URB buffer is freed using the OUT endpoint's maximum packet size (`max_out_size`) instead of the IN endpoint's size (`max_in_size`).
--

commit 17e5a8f2368ac7dba16afa9f23358b3fa3dba6de
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging

This commit fixes an out-of-bounds read in the debug logging of
ims_pcu_irq(). It updates the dev_dbg() call to print data from the
transfer_buffer associated with the URB rather than unconditionally
using the input URB buffer.

> diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
> index 55e5599cf5107..d7a3f4c7214a0 100644
> --- a/drivers/input/misc/ims-pcu.c
> +++ b/drivers/input/misc/ims-pcu.c
> @@ -1529,7 +1529,7 @@ static void ims_pcu_irq(struct urb *urb)
>  	}
>  
>  	dev_dbg(pcu->dev, "%s: received %d: %*ph\n", __func__,
> -		urb->actual_length, urb->actual_length, pcu->urb_in_buf);
> +		urb->actual_length, urb->actual_length, urb->transfer_buffer);
>  
>  	if (urb == pcu->urb_in)
>  		ims_pcu_process_data(pcu, urb);

[Severity: High]
This is a pre-existing issue, but I noticed a problem with how the memory for
the IN URB buffer is managed when reviewing this driver.

Does this code pass the correct size to the DMA free function?

Looking at ims_pcu_buffers_free(), the input buffer is freed using
max_out_size instead of max_in_size:

drivers/input/misc/ims-pcu.c:ims_pcu_buffers_free() {
    ...
	usb_free_coherent(pcu->udev, pcu->max_out_size,
			  pcu->urb_in_buf, pcu->read_dma);
    ...
}

The buffer is originally allocated in ims_pcu_buffers_alloc() using
max_in_size:

drivers/input/misc/ims-pcu.c:ims_pcu_buffers_alloc() {
    ...
	pcu->urb_in_buf = usb_alloc_coherent(pcu->udev, pcu->max_in_size,
					     GFP_KERNEL, &pcu->read_dma);
    ...
}

Is it possible that max_in_size and max_out_size are different?

USB endpoints can have asymmetric packet sizes, so max_in_size and max_out_size
are not guaranteed to be identical.

Could this mismatch between the allocation size and the free size lead to DMA
pool corruption or memory leaks?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260523050634.501509-1-dmitry.torokhov@gmail.com?part=8

  reply	other threads:[~2026-05-23  5:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-23  5:06 [PATCH 01/11] Input: ims-pcu - release data interface on disconnect Dmitry Torokhov
2026-05-23  5:06 ` [PATCH 02/11] Input: ims-pcu - fix use-after-free and double-free in disconnect Dmitry Torokhov
2026-05-23  5:45   ` sashiko-bot
2026-05-23  5:06 ` [PATCH 03/11] Input: ims-pcu - fix type confusion in CDC union descriptor parsing Dmitry Torokhov
2026-05-23  5:52   ` sashiko-bot
2026-05-23  5:06 ` [PATCH 04/11] Input: ims-pcu - fix firmware leak in async update Dmitry Torokhov
2026-05-23  5:37   ` sashiko-bot
2026-05-23  5:06 ` [PATCH 05/11] Input: ims-pcu - fix race condition in reset_device sysfs callback Dmitry Torokhov
2026-05-23  7:12   ` sashiko-bot
2026-05-23  5:06 ` [PATCH 06/11] Input: ims-pcu - validate control endpoint type Dmitry Torokhov
2026-05-23  5:44   ` sashiko-bot
2026-05-23  5:06 ` [PATCH 07/11] Input: ims-pcu - fix logic error in packet reset Dmitry Torokhov
2026-05-23  6:25   ` sashiko-bot
2026-05-23  5:06 ` [PATCH 08/11] Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging Dmitry Torokhov
2026-05-23  5:39   ` sashiko-bot [this message]
2026-05-23  5:06 ` [PATCH 09/11] Input: ims-pcu - fix DMA mapping violation in line setup Dmitry Torokhov
2026-05-23  5:37   ` sashiko-bot
2026-05-23  5:06 ` [PATCH 10/11] Input: ims-pcu - add response length checks Dmitry Torokhov
2026-05-23  5:54   ` sashiko-bot
2026-05-23  5:06 ` [PATCH 11/11] Input: ims-pcu - fix potential infinite loop in CDC union descriptor parsing Dmitry Torokhov
2026-05-23  6:02   ` sashiko-bot
2026-05-23  5:46 ` [PATCH 01/11] Input: ims-pcu - release data interface on disconnect sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260523053927.3FAE11F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox