On Thu, 12 Feb 2026 06:47:36 -0500
Aby Sam Ross <[email protected]> wrote:
> vfio-pci hostdev realize during zpci hot plug fails (in `vfio_pci_realize()`)
> if the vfio group file in `/dev/vfio/` lacks appropriate permissions and the
> hostdev[/properties] addition doesn't reach the point where it could be
> associated with previously added zpci device (in `s390_pcihost_plug()`).
> As a result, zpci iommu pointer remains null. The zpci hot unplug following
> the
> failed hostdev addition assumes zpci iommu pointer was assigned and tries to
> make use of it to end the dma count resulting in a null pointer dereference.
> In the non-hotplug scenario, `qdev_unplug()` for the zpci device is not called
> after hostdev addition failure and this issue is not encountered.
Maybe add a word or two why the other dereferences of pbdev->iommu
not guarded by a null check are safe.
I think we have:
* s390_pci_sclp_deconfigure
* s390_pci_msix_init
* s390_pcihost_reset
* s390_pci_device_reset
* mpcifc_service_call
* stpcifc_service_call
* s390_pci_read_base
and more. My guess is that the device never gets into a state where
these operations are permissible, and the code makes sure
those functions won't be called on a device that has
pbdev->iommu == NULL. But that is just my guess.
DISCLAIMER: I didn't look at this properly, just asking based
on a quick look. Some of these may contain explicit or implicit
checking...
Regards,
Halil
>
> Fixes: 37fa32de7073 ("s390x/pci: Honor DMA limits set by vfio")
>
> Signed-off-by: Aby Sam Ross <[email protected]>
> Acked-by: Eric Farman <[email protected]>
> Reviewed-by: Matthew Rosato <[email protected]>
> Reviewed-by: Farhan Ali <[email protected]>
