From f607a40a84b80b2cb33ef3bb42b60b84af596cc9 Mon Sep 17 00:00:00 2001 From: Thomas Huth Date: Tue, 18 Nov 2025 18:40:47 +0100 Subject: [PATCH 3/4] hw/s390x: Fix a possible crash with passed-through virtio devices MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit RH-Author: Thomas Huth RH-MergeRequest: 427: s390x: Fix a possible crash with passed-through virtio devices RH-Jira: RHEL-128085 RH-Acked-by: Cornelia Huck RH-Acked-by: Cédric Le Goater RH-Commit: [1/1] a368a65a46a8d85f7ae83cfb5af23b1a341ea9d4 (thuth/qemu-kvm-cs) JIRA: https://issues.redhat.com/browse/RHEL-128085 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. Reviewed-by: Halil Pasic Reviewed-by: Eric Farman Tested-by: Eric Farman Reviewed-by: Cornelia Huck Acked-by: Christian Borntraeger Signed-off-by: Thomas Huth Message-ID: <20251118174047.73103-1-thuth@redhat.com> (cherry picked from commit e5cb62e7b6f99d45a42f0cd358d76d6ee2cef5cd) --- hw/s390x/s390-hypercall.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/hw/s390x/s390-hypercall.c b/hw/s390x/s390-hypercall.c index ac1b08b2cd..508dd97ca0 100644 --- a/hw/s390x/s390-hypercall.c +++ b/hw/s390x/s390-hypercall.c @@ -10,6 +10,7 @@ */ #include "qemu/osdep.h" +#include "qemu/error-report.h" #include "cpu.h" #include "hw/s390x/s390-virtio-ccw.h" #include "hw/s390x/s390-hypercall.h" @@ -42,6 +43,19 @@ static int handle_virtio_ccw_notify(uint64_t subch_id, uint64_t data) if (!sch || !css_subch_visible(sch)) { return -EINVAL; } + if (sch->id.cu_type != VIRTIO_CCW_CU_TYPE) { + /* + * This might happen in nested setups: If the L1 host defined the + * L2 guest with a virtio device (e.g. virtio-keyboard), and the + * L2 guest passes this device through to the L3 guest, the L3 guest + * might send virtio notifications to the QEMU in L2 for that device. + * But since the QEMU in L2 defined this device as vfio-ccw, it's not + * a VirtIODevice that we can handle here! + */ + warn_report_once("Got virtio notification for unsupported device " + "on subchannel %02x.%1x.%04x!", cssid, ssid, schid); + return -EINVAL; + } vdev = virtio_ccw_get_vdev(sch); if (vq_idx >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev, vq_idx)) { -- 2.47.3