Re: [PATCH] hw/usb/hcd-ohci: Fail iso packets sent to non-iso endpoints and vice-versa

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Oct 02, 2026 at 11:33:10AM +0100, Peter Maydell wrote:
> On Fri, 2 Oct 2026 at 11:22, Thomas Huth <thuth@redhat.com> wrote:
> >
> > On 01/10/2026 21.47, Peter Maydell wrote:
> > > The OHCI USB controller requires software to set up an Endpoint
> > > Descriptor data structure.  This specifies (among other things) both
> > > an EndpointNumber telling the controller which USB endpoint to talk
> > > to, and a Format (F) bit which is 1 for Isochronous transfers and 0
> > > for General transfers.
> > >
> > > The specification requires that software matches the F bit with the
> > > endpoint it's setting up the descriptor for, so that Control, Bulk
> > > and Interrupt endpoints use F=0, and Isochronous endpoints use F=1.
> > > It doesn't require the controller to check whether software gets this
> > > right.
> > >
> > > The spec isn't totally clear about what happens if software creates
> > > an ED with a mismatch, but I believe that the controller just trusts
> > > the F bit, and tries to talk to the endpoint with the wrong sequence
> > > of USB tokens (notably, isochronous transactions have no handshaking
> > > and the others do). This probably results in the transfer failing.
> > >
> > > In hcd-ehci.c we check for the "iso transfer to non-iso endpoint" and
> > > make it fail, but we don't do this in hcd-ohci.c.  The result is that
> > > a guest that deliberately sets up this situation can cause us to hit
> > > the assertion added in commit 7b1eba96aeca, where the endpoint is not
> > > isochronous and returns USB_RET_ASYNC to an iso TD handling function
> > > that isn't prepared to deal with that.
> > >
> > > Add checks for both "iso transfer to non-iso endpoint" and "non-iso
> > > transfer to iso endpoint" and make those TDs fail rather than blindly
> > > sending them to the endpoint.
> > >
> > > Cc: qemu-stable@nongnu.org
> > > Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3729

Change that to 'Related', since the assert fix you mention below is
what actually Resolves that issue initially

> > Looks like this issue got assigned with a CVE number, so please add:
> >
> > CVE: CVE-2026-7180
> 
> I guess we might as well, but honestly I don't think this is CVE worthy,
> and I can't find any record of what that CVE number is supposed to cover
> from a websearch.

This issue originated on the qemu-security list, and we declared it
a CVE because it was a guest triggerable use-after-free originally.

> This is in OHCI, which I thought was agreed to be outside
> the security envelope, and in any case it's only an assertion failure.
> 
> The use-after-free that was the original subject of the bug report
> has already been fixed by 7b1eba96aeca (which downgraded it to
> "fails assertion").

Ok, that commit is the one that should have been tagged with the CVE.

This commit is just a nice followup.

> 
> thanks
> -- PMM
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|