All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Reid D <skibletz@gmail.com>, linux-usb@vger.kernel.org
Subject: Re: usb: devio: USBFS_XFER_MAX check bypassed for iso urbs due to incorrect ordering, potential oob heap write
Date: Thu, 15 Oct 2026 17:26:18 +0200	[thread overview]
Message-ID: <2026101546-civic-gorged-3023@gregkh> (raw)
In-Reply-To: <747393c4-4824-4a06-9747-3fd74028c2d7@rowland.harvard.edu>

On Thu, Oct 15, 2026 at 10:54:31AM -0400, Alan Stern wrote:
> On Thu, Oct 15, 2026 at 08:07:49AM -0400, Reid D wrote:
> > Greg, sorry about that.
> > 
> > The fix moves the USBFS_XFER_MAX check to after totlen is computed so it
> > validates the actual transfer size used for the kmalloc.
> 
> It isn't necessary to do this.  The check you added can never be 
> violated.
> 
> To see why, read the code.  The first thing the USBDEVFS_URB_TYPE_ISO 
> case does is ensure that uurb->number_of_packets <= 128.  The loop that 
> accumulates the individual packet sizes also limits isopkt[u].length to 
> be <= 98304.  Therefore the largest possible buffer size for an 
> isochronous transfer is 128 * 98304 = 12582912.  But USBFS_XFER_MAX is 
> (UINT_MAX / 2 - 1000000) or 2146483648, which is a lot bigger (about 2 
> billion vs. 12 million).  This means the calculated value for 
> uurb->buffer_length cannot exceed USBFS_XFER_MAX.
> 
> The real point of the USBFS_XFER_MAX check is to limit the size of bulk 
> and interrupt transfers.

Awe, you spoiled the test :)

Reid, again, remember that the _BEST_ LLM right now (top of the line,
frontier model, no guardrails) makes up patches that are 50% of the time
wrong.  You MUST have a reproducer to have a LLM be able to prove it, OR
take the time to manually review it yourself.

Best of luck!

greg k-h

  reply	other threads:[~2026-10-15 15:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAGNJ+_3qpWtzjTLntxTzF2v0jU9mVssukGfhrJFOx_yb+2Abyg@mail.gmail.com>
2026-10-15  5:18 ` usb: devio: USBFS_XFER_MAX check bypassed for iso urbs due to incorrect ordering, potential oob heap write Greg KH
     [not found]   ` <CAGNJ+_0ShEM-G+8p3oHx1uF8rBtC7JyqmyFzswDB50qsW=qwuw@mail.gmail.com>
     [not found]     ` <2026101509-reggae-whacking-6598@gregkh>
2026-10-15 12:07       ` Reid D
2026-10-15 12:32         ` Greg KH
2026-10-15 14:54         ` Alan Stern
2026-10-15 15:26           ` Greg KH [this message]
2026-10-15 15:36             ` Alan Stern

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=2026101546-civic-gorged-3023@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=skibletz@gmail.com \
    --cc=stern@rowland.harvard.edu \
    /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.