All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "YuanZhe Liu" <25031212351@stu.xidian.edu.cn>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH v2] usb: usbtest: reject transfer lengths the allocator cannot serve
Date: Fri, 16 Oct 2026 16:02:40 +0000	[thread overview]
Message-ID: <sashiko-outbox-174594@kernel.org> (raw)
In-Reply-To: <20261016154707.13098-1-25031212351@stu.xidian.edu.cn>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] usb: division by zero in simple_io() when length is 0
- [Medium] usb: usbtest: incomplete limit in iso_alloc_urb allows MAX_PAGE_ORDER bypass
--

commit 805535b4eccf7c27a2100576fca5ef6fb016a6bd
Author: YuanZhe Liu <25031212351@stu.xidian.edu.cn>

usb: usbtest: reject transfer lengths the allocator cannot serve

This commit restricts the length parameter of usbtest ioctls to ensure it
doesn't exceed KMALLOC_MAX_SIZE. It aims to fix warnings from the page
allocator when a large parameter length triggers allocations above
MAX_PAGE_ORDER.

> diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
> index 8759df49be287..6a3394800fd86 100644
> --- a/drivers/usb/misc/usbtest.c
> +++ b/drivers/usb/misc/usbtest.c
> @@ -2192,6 +2192,9 @@ usbtest_do_ioctl(struct usb_interface *intf, struct usbtest_param_32 *param)
>  		return -EINVAL;
>  	if (param->sglen > MAX_SGLEN)
>  		return -EINVAL;
> +	/* Don't allow unreasonably large transfer-buffer allocations */
> +	if (param->length >= KMALLOC_MAX_SIZE)
> +		return -EINVAL;

[Severity: High]
Does this check also need to ensure param->length > 0?

If userspace provides param->length == 0 and param->vary != 0 for test cases
3 or 4, simple_alloc_urb() succeeds and returns an URB with
transfer_buffer_length = 0.

When simple_io() is called:

drivers/usb/misc/usbtest.c:simple_io() {
    ...
	int max = urb->transfer_buffer_length; /* max becomes 0 */
    ...
		if (vary) {
			int len = urb->transfer_buffer_length;

			len += vary;
			len %= max;
    ...
}

Can this division by zero trigger a kernel panic?

[Severity: Medium]
Is this upper bound check sufficient for isochronous transfers in tests 15
and 16?

For these tests, test_queue() calls iso_alloc_urb() which allocates the URB
based on the number of packets:

drivers/usb/misc/usbtest.c:iso_alloc_urb() {
    ...
	maxp = usb_endpoint_maxp(desc);
    ...
	packets = DIV_ROUND_UP(bytes, maxp);
	urb = usb_alloc_urb(packets, GFP_KERNEL);
    ...
}

If a malicious or dummy USB device provides an isochronous endpoint with a
small maxp (e.g., 1), packets will equal param->length. usb_alloc_urb() will
then allocate memory sized for the URB and its packet descriptors:
sizeof(struct urb) + packets * sizeof(struct usb_iso_packet_descriptor).
This is roughly 192 + param->length * 16 bytes.

If param->length is just below KMALLOC_MAX_SIZE, the resulting allocation
size passed to kmalloc() will be roughly 16 times KMALLOC_MAX_SIZE. Does
this exceed MAX_PAGE_ORDER and trigger the exact same warning this patch
attempts to fix?

>  	/*
>  	 * Just a bunch of test cases that every HCD is expected to handle.
>  	 *

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016154707.13098-1-25031212351@stu.xidian.edu.cn?part=1

      reply	other threads:[~2026-10-16 16:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16  9:48 [PATCH] usb: usbtest: reject transfer lengths the allocator cannot serve YuanZhe Liu
2026-10-16 10:01 ` sashiko-bot
2026-10-16 15:08 ` Alan Stern
2026-10-16 15:47 ` [PATCH v2] " YuanZhe Liu
2026-10-16 16:02   ` sashiko-bot [this message]

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=sashiko-outbox-174594@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=25031212351@stu.xidian.edu.cn \
    --cc=linux-usb@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.