Re: [PATCH] hw/usb/hcd-xhci: Fix endless loop in case the DMA access fails (CVE-2020-14394)

[Thomas Huth <thuth@redhat.com>]

On 16/08/2022 10.37, Gerd Hoffmann wrote:
> On Thu, Aug 04, 2022 at 01:43:14PM +0200, Thomas Huth wrote:
>> On 04/08/2022 12.17, Peter Maydell wrote:
>>> That sounds like we do still have an unbounded-loop problem,
>>> then: there's no limit on the number of consecutive TRBs
>>> we try to read in that function. Maybe we're missing an
>>> error check of some kind (does the spec limit how many
>>> consecutive TRBs there can be somehow?) or else we need
>>> another artificial limit.
>>
>> I'm not an XHCI expert at all, but while at least having a quick glance at
>> the spec, I did not see any limit there. So I assume that we should enforce
>> an artificial limit? What would be a good value for this? Gerd, do you maybe
>> have any opinion?
> 
> Hmm, dunno.  Typical workflow is that the driver allocates a page
> (or multiple physically contiguous pages) for the TRBs, and when
> it reaches the end of the allocation it gets a new block and chains
> it using TRB_LINK.
> 
> Right now we have a limit for type=TRB_LINK only, having another one for
> all TRBs makes sense.  The number of TRBs for a transfer can be quite
> large (think usb-storage reads/writes), so don't set that too low, 64k
> maybe?

Yes, after some more reading, I found a remark in the spec (in chapter 6) 
saying that each segment should be limited by 64 kb.

I've sent a v2 with that limit check here (it has a slightly different 
subject, so it's hard to relate it to this v1 here):

 
https://patchwork.kernel.org/project/qemu-devel/patch/20220804131300.96368-1-thuth@redhat.com/

  Thomas