All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH 02/11] Input: ims-pcu - fix use-after-free and double-free in disconnect
Date: Sat, 23 May 2026 05:45:38 +0000	[thread overview]
Message-ID: <20260523054538.5615B1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260523050634.501509-2-dmitry.torokhov@gmail.com>

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

New issues:
- [High] Concurrent unbinding of both the control and data interfaces via sysfs triggers a Use-After-Free on the `pcu` structure.

Pre-existing issues:
- [Critical] The driver blindly trusts the CDC Union Descriptor to identify interfaces, leading to memory corruption during probe and an unconditional NULL pointer dereference in disconnect.
- [High] In `ims_pcu_buffers_free`, the input DMA buffer is freed using the maximum output buffer size instead of its actual allocated size.
--

commit 73572626cc6ab15fc9107238c7a713e379862dd8
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: ims-pcu - fix use-after-free and double-free in disconnect

This commit changes the interface verification in ims_pcu_disconnect() to
directly compare the disconnecting interface against the saved control
interface pointer. This prevents premature cleanup caused by malicious
devices presenting multiple interfaces with the same class.

> diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
> index 89737ef381c1c..2ad72fe4a51d9 100644
> --- a/drivers/input/misc/ims-pcu.c
> +++ b/drivers/input/misc/ims-pcu.c
> @@ -2071,7 +2071,6 @@ static int ims_pcu_probe(struct usb_interface *intf,
>  static void ims_pcu_disconnect(struct usb_interface *intf)
>  {
>  	struct ims_pcu *pcu = usb_get_intfdata(intf);
> -	struct usb_host_interface *alt = intf->cur_altsetting;
>  
>  	usb_set_intfdata(intf, NULL);
>  
> @@ -2079,7 +2078,7 @@ static void ims_pcu_disconnect(struct usb_interface *intf)
>  	 * See if we are dealing with control or data interface. The cleanup
>  	 * happens when we unbind primary (control) interface.
>  	 */
> -	if (alt->desc.bInterfaceClass != USB_CLASS_COMM)
> +	if (intf != pcu->ctrl_intf)

[Severity: High]
Can this introduce a use-after-free if both control and data interfaces are
unbound concurrently via sysfs?

If Process A unbinds the data interface, it gets the pcu pointer from
usb_get_intfdata() and might be preempted. The USB core sets the data
interface condition to USB_INTERFACE_UNBINDING.

Process B then unbinds the control interface, enters ims_pcu_disconnect(),
and calls usb_driver_release_interface() on the data interface.

Since the data interface is unbinding, usb_driver_release_interface() returns
immediately without waiting, and Process B proceeds to kfree(pcu).

When Process A resumes, evaluating intf != pcu->ctrl_intf would dereference
the freed pcu pointer.

[Severity: Critical]
This is a pre-existing issue, but does this new check introduce an
unconditional NULL pointer dereference if the CDC Union Descriptor is spoofed?

During ims_pcu_probe(), the driver uses bMasterInterface0 from the CDC Union
Descriptor as pcu->ctrl_intf without verifying it matches the probed
interface.

If a malicious device supplies a descriptor pointing to an interface owned by
another driver, the actual probed interface's intfdata remains NULL.

In that scenario, usb_get_intfdata() returns NULL for pcu, and evaluating
intf != pcu->ctrl_intf here will panic. Note that this is fixed later in the
patch series by commit af29ec151c71a.

>  		return;
>  
>  	ims_pcu_stop_io(pcu);

[Severity: High]
This is a pre-existing issue, but could ims_pcu_buffers_free() be freeing
the input buffer with the wrong size?

Looking at ims_pcu_buffers_alloc(), pcu->urb_in_buf is allocated using
pcu->max_in_size. However, ims_pcu_buffers_free() appears to free it using
pcu->max_out_size:

usb_free_coherent(pcu->udev, pcu->max_out_size, pcu->urb_in_buf,
                  pcu->read_dma);

If a device specifies different maximum packet sizes for IN and OUT endpoints,
calling usb_free_coherent() with the wrong size could corrupt the DMA
allocator's buddy system.

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

  reply	other threads:[~2026-05-23  5:45 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 [this message]
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
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=20260523054538.5615B1F00A3A@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.