linux-kernel - Re: Re: [usb-storage] Re:Re:[PATCH] usb: storage: Fix `us->iobuf` size for BOT transmission to prevent memory overflow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAA6KcBD=CbW6S8vZ-n2v4BuJfC03vuNPzAG-WD5AN5_mMjgUfw@mail.gmail.com>
Date: Sat, 15 Mar 2025 02:37:38 -0700
From: Matthew Dharm <mdharm-usb@...-eyed-alien.net>
To: daixin_tkzc <daixin_tkzc@....com>
Cc: Alan Stern <stern@...land.harvard.edu>, Greg KH <gregkh@...uxfoundation.org>, 
	linux-usb@...r.kernel.org, usb-storage@...ts.one-eyed-alien.net, 
	linux-kernel@...r.kernel.org
Subject: Re: Re: [usb-storage] Re:Re:[PATCH] usb: storage: Fix `us->iobuf`
 size for BOT transmission to prevent memory overflow

On Sat, Mar 15, 2025 at 2:05 AM daixin_tkzc <daixin_tkzc@....com> wrote:
> Yes, dwc_otg should indeed ensure that DMA writes memory data no more than 13 bytes (even if Rxfifo receives 512 bytes).
> But in fact, the dwc_otg manual has different configuration requirements for the XferSize register before DMA transfer:
> For BOT's OUT transaction, the HCTSIZ register is filled with as many bytes as the software requests to send; for IN transactions, no matter how many bytes the software requests to receive, the HCTSIZ register needs to be filled with 512 alignment, that is, the software requests 31 bytes in the CBW phase, and HCTSIZ is filled with 31; the software requests 13 bytes in the CSW phase, and HCTSIZ is still filled with 512.

"Alignment" is not the same thing as "size".  A buffer can be 32 bytes
and aligned on a 4MByte boundary.  Hardware devices often impose
alignment requirements as it simplifies the logic required to access
the buffer.

> Please allow us to explain the reason behind changing the US_IOBUF_SIZE macro.
> 1) The macro comment says, “But Freecom needs a 64-byte buffer, so that's the
> size we'll allocate”. We thought that "Freecom" had a similar problem, otherwise a 32-byte buffer size would be enough.

Your reasoning is incorrect.  The "Freecom" device does NOT have a
babble problem.  The Freecom device uses a vendor-specific protocol
which requires a 64-byte buffer buffer for all of its command and
status transfers.  us->iobuf is used by multiple protocols for command
and status, including CB, CBI, BOT, Freecom, and others -- as such, it
needs to be the largest size required by any of those protocols.

Matt