[Qemu-devel] xhci: guard xhci_kick_epctx against recursive calls for 2.8?

[Qemu-devel] xhci: guard xhci_kick_epctx against recursive calls for 2.8?

[Michael Tokarev]

After applying commit 96d87bdda3919bb16f754b3d3fd1227e1f38f13c:

Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Thu Feb 2 12:36:12 2017 +0100

    xhci: guard xhci_kick_epctx against recursive calls

    Track xhci_kick_epctx processing being active in a variable.  Check the
    variable before calling xhci_kick_epctx from xhci_kick_ep.  Add an
    assert to make sure we don't call recursively into xhci_kick_epctx.

    Cc: 1653384@bugs.launchpad.net
    Fixes: 94b037f2a451b3dc855f9f2c346e5049a361bd55
    Reported-by: Fabian Lesniak <fabian@lesniak-it.de>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Message-id: 1486035372-3621-1-git-send-email-kraxel@redhat.com
    Message-id: 1485790607-31399-5-git-send-email-kraxel@redhat.com

to 2.8, to fix the CVE-2017-9375 in 2.8, it starts to fail at
startup with the assertion failure introduced in this commit:

 hw/usb/hcd-xhci.c:2169: xhci_kick_epctx: Assertion `!epctx->kick_active' failed.

The commit itself looks sane, but might be there were other
fixes before this one, on top of 2.8, required for it to
functioning properly?  I'm not sure I understand the xhci
machinery right.

Gerd, can you shed some light on this please?

Thank you!

/mjt

Re: [Qemu-devel] xhci: guard xhci_kick_epctx against recursive calls for 2.8?

[Gerd Hoffmann]

> After applying commit 96d87bdda3919bb16f754b3d3fd1227e1f38f13c:
> 
> Author: Gerd Hoffmann <kraxel@redhat.com>
> Date:   Thu Feb 2 12:36:12 2017 +0100
> 
>     xhci: guard xhci_kick_epctx against recursive calls

> to 2.8, to fix the CVE-2017-9375 in 2.8, it starts to fail at
> startup with the assertion failure introduced in this commit:
> 
>  hw/usb/hcd-xhci.c:2169: xhci_kick_epctx: Assertion `!epctx-
> >kick_active' failed.
> 
> The commit itself looks sane, but might be there were other
> fixes before this one, on top of 2.8, required for it to
> functioning properly?  I'm not sure I understand the xhci
> machinery right.

ddb603ab6c981c1d67cb42266fc700c33e5b2d8f probably.

13e8ff7abbf1dde46280536ab4fae5012661b8b0 should help too, for cherry-
picking without conflicts.

(just back from vacation).

cheers,
  Gerd