On Mon, 2021-10-25 at 09:49 +0200, Greg KH wrote:
> On Thu, Oct 21, 2021 at 04:13:41PM +0200, Niklas Schnelle wrote:
> > commit a46044a92add6a400f4dada7b943b30221f7cc80 upstream.
> >
> > Since commit 2a671f77ee49 ("s390/pci: fix use after free of zpci_dev")
> > the reference count of a zpci_dev is incremented between
> > pcibios_add_device() and pcibios_release_device() which was supposed to
> > prevent the zpci_dev from being freed while the common PCI code has
> > access to it. It was missed however that the handling of zPCI
> > availability events assumed that once zpci_zdev_put() was called no
> > later availability event would still see the device. With the previously
> > mentioned commit however this assumption no longer holds and we must
> > make sure that we only drop the initial long-lived reference the zPCI
> > subsystem holds exactly once.
> >
> > Do so by introducing a zpci_device_reserved() function that handles when
> > a device is reserved. Here we make sure the zpci_dev will not be
> > considered for further events by removing it from the zpci_list.
> >
> > This also means that the device actually stays in the
> > ZPCI_FN_STATE_RESERVED state between the time we know it has been
> > reserved and the final reference going away. We thus need to consider it
> > a real state instead of just a conceptual state after the removal. The
> > final cleanup of PCI resources, removal from zbus, and destruction of
> > the IOMMU stays in zpci_release_device() to make sure holders of the
> > reference do see valid data until the release.
> >
> > Fixes: 2a671f77ee49 ("s390/pci: fix use after free of zpci_dev")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
> > Signed-off-by: Vasily Gorbik <gor@xxxxxxxxxxxxx>
>
> This is also needed for 5.10.y, can you please provide a working
> backport for that tree too?
>
> thanks,
>
> greg k-h
Hi Greg,
Sorry again for the confusion. For v5.10.y the backport I sent
originally is the correct one. I had replied there explaining that
backporting the prerequisite commit to v5.10.y makes little sense
because the flag it checks isn't there yet. The backport for v5.10 also
doesn't subsume the prerequisite commits change. I guess this reply was
missed. I'll resent anyway then we have both v5.14.y and v5.10.y sent
today and easier to find.
Thanks,
Niklas
