On Tue, Nov 18 2025, Thomas Huth <[email protected]> wrote: > From: Thomas Huth <[email protected]> > > Consider the following nested setup: An L1 host uses some virtio device > (e.g. virtio-keyboard) for the L2 guest, and this L2 guest passes this > device through to the L3 guest. Since the L3 guest sees a virtio device, > it might send virtio notifications to the QEMU in L2 for that device. > But since the QEMU in L2 defined this device as vfio-ccw, the function > handle_virtio_ccw_notify() cannot handle this and crashes: It calls > virtio_ccw_get_vdev() that casts sch->driver_data into a VirtioCcwDevice, > but since "sch" belongs to a vfio-ccw device, that driver_data rather > points to a CcwDevice instead. So as soon as QEMU tries to use some > VirtioCcwDevice specific data from that device, we've lost. > > We must not take virtio notifications for such devices. Thus fix the > issue by adding a check to the handle_virtio_ccw_notify() handler to > refuse all devices that are not our own virtio devices. Like in the > other branches that detect wrong settings, we return -EINVAL from the > function, which will later be placed in GPR2 to inform the guest about > the error. > > Signed-off-by: Thomas Huth <[email protected]> > --- > v3: Print the subchannel number to ease debugging > > hw/s390x/s390-hypercall.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) >
Reviewed-by: Cornelia Huck <[email protected]>
