From: Peter Maydell <peter.maydell@linaro.org>
To: Jenny Guanni Qu <qguanni@gmail.com>
Cc: qemu-devel@nongnu.org, berrange@redhat.com, mcascell@redhat.com,
qemu-security@nongnu.org
Subject: Re: [PATCH] hw/usb/hcd-ohci: check for MPS=0 to avoid infinite loop
Date: Thu, 19 Mar 2026 17:34:28 +0000 [thread overview]
Message-ID: <CAFEAcA_tiZT=vhEvtS3VAgjJLrYEZDBTQxm5xbbWmTBm8DLnng@mail.gmail.com> (raw)
In-Reply-To: <20260318193610.2043847-1-qguanni@gmail.com>
On Wed, 18 Mar 2026 at 19:36, Jenny Guanni Qu <qguanni@gmail.com> wrote:
>
> When a guest sets MaxPacketSize to 0 in an OHCI Endpoint Descriptor,
> ohci_service_td() transfers 0 bytes per iteration. The Transfer
> Descriptor never completes because CBP never advances toward BE,
> causing ohci_service_ed_list() to loop indefinitely and hang QEMU.
>
> Add a check for MPS==0 after extracting the field from ED flags.
> If MPS is zero, call ohci_die() to reset the controller and return
> an error, preventing the infinite loop.
>
> Fixes: CVE-2026-3890
> Reported-by: Jenny Guanni Qu <qguanni@gmail.com>
> Signed-off-by: Jenny Guanni Qu <qguanni@gmail.com>
> ---
> hw/usb/hcd-ohci.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c
> index 1aeed9286f..b93a99593e 100644
> --- a/hw/usb/hcd-ohci.c
> +++ b/hw/usb/hcd-ohci.c
> @@ -956,6 +956,10 @@ static int ohci_service_td(OHCIState *ohci, struct ohci_ed *ed)
> if (len && dir != OHCI_TD_DIR_IN) {
> /* The endpoint may not allow us to transfer it all now */
> pktlen = (ed->flags & OHCI_ED_MPS_MASK) >> OHCI_ED_MPS_SHIFT;
> + if (pktlen == 0) {
> + ohci_die(ohci);
> + return 1;
> + }
The OHCI spec doesn't (as far as I can tell) say what the
hardware should do for this situation, so I guess "flag it
as an error" is a reasonable choice. I think it would be
useful to note in a comment that this is our best-guess, though:
/*
* The OHCI spec doesn't say what to do if the guest hands us
* an endpoint descriptor which specifies a MaximumPacketSize
* of zero, which would mean we can never actually make forward
* progress transferring data to it. We choose to treat it as
* an error.
*/
With something like that,
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
(Or if I've missed something in the spec, let me know...)
thanks
-- PMM
next prev parent reply other threads:[~2026-03-19 17:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 19:36 [PATCH] hw/usb/hcd-ohci: check for MPS=0 to avoid infinite loop Jenny Guanni Qu
2026-03-19 17:34 ` Peter Maydell [this message]
2026-03-21 0:05 ` Guanni Qu
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='CAFEAcA_tiZT=vhEvtS3VAgjJLrYEZDBTQxm5xbbWmTBm8DLnng@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=berrange@redhat.com \
--cc=mcascell@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-security@nongnu.org \
--cc=qguanni@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox