SWSA#4992cdf0-415c-45c1-be1a-71213467347d

The `virtio_ccw_get_vdev()` function can return a `NULL` pointer if the
corresponding subchannel driver data (`sch->driver_data`) is not initialized
or has been cleared.

If `vdev` is `NULL`, passing it directly into 
`virtio_queue_get_num(vdev, vq_idx)`
results in a `NULL` pointer dereference, which can lead to a hypervisor
crash or unexpected termination of the QEMU process.

Fix this by adding an explicit check for `!vdev` before verifying the
queue index and its capacity, returning `-EINVAL` early if the device
is missing or not bound to the subchannel.

Signed-off-by: Nikolay N Zorin <zorin@swemel.ru>
---
  hw/s390x/s390-hypercall.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/s390x/s390-hypercall.c b/hw/s390x/s390-hypercall.c
index ac1b08b2..fd2972c0 100644
--- a/hw/s390x/s390-hypercall.c
+++ b/hw/s390x/s390-hypercall.c
@@ -44,7 +44,7 @@ static int handle_virtio_ccw_notify(uint64_t subch_id, 
uint64_t data)
      }

      vdev = virtio_ccw_get_vdev(sch);
-    if (vq_idx >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev, 
vq_idx)) {
+    if (!vdev || vq_idx >= VIRTIO_QUEUE_MAX || 
!virtio_queue_get_num(vdev, vq_idx)) {
          return -EINVAL;
      }
-- 
2.43.0

On Tue, Sep 15, 2026 at 07:17:28PM +0300, Николай Зорин wrote:
> SWSA#4992cdf0-415c-45c1-be1a-71213467347d
> 
> The `virtio_ccw_get_vdev()` function can return a `NULL` pointer if the
> corresponding subchannel driver data (`sch->driver_data`) is not initialized
> or has been cleared.

and when does this happen?

> If `vdev` is `NULL`, passing it directly into `virtio_queue_get_num(vdev,
> vq_idx)`
> results in a `NULL` pointer dereference, which can lead to a hypervisor
> crash or unexpected termination of the QEMU process.
> 
> Fix this by adding an explicit check for `!vdev` before verifying the
> queue index and its capacity, returning `-EINVAL` early if the device
> is missing or not bound to the subchannel.


Please do not use this style with `` - there's no reason to. Just
say NULL -EINVAL etc normally.

> 
> Signed-off-by: Nikolay N Zorin <zorin@swemel.ru>
> ---
>  hw/s390x/s390-hypercall.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/s390x/s390-hypercall.c b/hw/s390x/s390-hypercall.c
> index ac1b08b2..fd2972c0 100644
> --- a/hw/s390x/s390-hypercall.c
> +++ b/hw/s390x/s390-hypercall.c
> @@ -44,7 +44,7 @@ static int handle_virtio_ccw_notify(uint64_t subch_id,
> uint64_t data)
>      }
> 
>      vdev = virtio_ccw_get_vdev(sch);
> -    if (vq_idx >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev, vq_idx))
> {
> +    if (!vdev || vq_idx >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev,
> vq_idx)) {
>          return -EINVAL;
>      }
> -- 
> 2.43.0

On 15/09/2026 18.17, Николай Зорин wrote:
> SWSA#4992cdf0-415c-45c1-be1a-71213467347d
> 
> The `virtio_ccw_get_vdev()` function can return a `NULL` pointer if the
> corresponding subchannel driver data (`sch->driver_data`) is not initialized
> or has been cleared.
> 
> If `vdev` is `NULL`, passing it directly into `virtio_queue_get_num(vdev, 
> vq_idx)`
> results in a `NULL` pointer dereference, which can lead to a hypervisor
> crash or unexpected termination of the QEMU process.
> 
> Fix this by adding an explicit check for `!vdev` before verifying the
> queue index and its capacity, returning `-EINVAL` early if the device
> is missing or not bound to the subchannel.
> 
> Signed-off-by: Nikolay N Zorin <zorin@swemel.ru>
> ---
>   hw/s390x/s390-hypercall.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/s390x/s390-hypercall.c b/hw/s390x/s390-hypercall.c
> index ac1b08b2..fd2972c0 100644
> --- a/hw/s390x/s390-hypercall.c
> +++ b/hw/s390x/s390-hypercall.c
> @@ -44,7 +44,7 @@ static int handle_virtio_ccw_notify(uint64_t subch_id, 
> uint64_t data)
>       }
> 
>       vdev = virtio_ccw_get_vdev(sch);
> -    if (vq_idx >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev, vq_idx)) {
> +    if (!vdev || vq_idx >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev, 
> vq_idx)) {
>           return -EINVAL;
>       }

  Hi!

How did you trigger this problem? It should not exist anymore since:

  https://gitlab.com/qemu-project/qemu/-/commit/e5cb62e7b6f9

which has been included since QEMU v10.2.

So please provide some description how to reproduce it if it still happens 
with the latest version of QEMU.

  Thanks,
   Thomas

PS: The list of maintainers for the s390x part of QEMU also has recently 
been changed. Please use the MAINTAINERS file and scripts/get_maintainer.pl 
from the latest version to check before sending patches. Thanks!

This is the reaction of the (dynamic) static analyzer. We conducted 
research (at the request of the quality department) and found out that 
it could work. So we created a patch.If you're sure it will never 
happen, then, of course, skip it (and I'll have to work hard, because 
the quality department is digging into everything).

15.09.2026 19:32, Thomas Huth пишет:
> On 15/09/2026 18.17, Николай Зорин wrote:
>> SWSA#4992cdf0-415c-45c1-be1a-71213467347d
>>
>> The `virtio_ccw_get_vdev()` function can return a `NULL` pointer if the
>> corresponding subchannel driver data (`sch->driver_data`) is not 
>> initialized
>> or has been cleared.
>>
>> If `vdev` is `NULL`, passing it directly into 
>> `virtio_queue_get_num(vdev, vq_idx)`
>> results in a `NULL` pointer dereference, which can lead to a hypervisor
>> crash or unexpected termination of the QEMU process.
>>
>> Fix this by adding an explicit check for `!vdev` before verifying the
>> queue index and its capacity, returning `-EINVAL` early if the device
>> is missing or not bound to the subchannel.
>>
>> Signed-off-by: Nikolay N Zorin <zorin@swemel.ru>
>> ---
>>   hw/s390x/s390-hypercall.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/s390x/s390-hypercall.c b/hw/s390x/s390-hypercall.c
>> index ac1b08b2..fd2972c0 100644
>> --- a/hw/s390x/s390-hypercall.c
>> +++ b/hw/s390x/s390-hypercall.c
>> @@ -44,7 +44,7 @@ static int handle_virtio_ccw_notify(uint64_t 
>> subch_id, uint64_t data)
>>       }
>>
>>       vdev = virtio_ccw_get_vdev(sch);
>> -    if (vq_idx >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev, 
>> vq_idx)) {
>> +    if (!vdev || vq_idx >= VIRTIO_QUEUE_MAX || 
>> !virtio_queue_get_num(vdev, vq_idx)) {
>>           return -EINVAL;
>>       }
>
>  Hi!
>
> How did you trigger this problem? It should not exist anymore since:
>
> https://gitlab.com/qemu-project/qemu/-/commit/e5cb62e7b6f9
>
> which has been included since QEMU v10.2.
>
> So please provide some description how to reproduce it if it still 
> happens with the latest version of QEMU.
>
>  Thanks,
>   Thomas
>
> PS: The list of maintainers for the s390x part of QEMU also has 
> recently been changed. Please use the MAINTAINERS file and 
> scripts/get_maintainer.pl from the latest version to check before 
> sending patches. Thanks!
>

On Tue, Sep 15, 2026 at 07:42:31PM +0300, Николай Зорин wrote:
> This is the reaction of the (dynamic) static analyzer. We conducted research
> (at the request of the quality department) and found out that it could work. So
> we created a patch. If you're sure it will never happen, then, of course, skip
> it (and I'll have to work hard, because the quality department is digging into
> everything).

It's contributor's job to test the code before and after the fix and
explain, in the commit log, what the issue is, how to reproduce it, and
what is the behaviour after the fix.

Without this information, the maintainers can't make an informed opinion
e.g. on whether the backport the patches.
-- 
MST

On 15/09/2026 18.42, Николай Зорин wrote:
> This is the reaction of the (dynamic) static analyzer. We conducted research 
> (at the request of the quality department) and found out that it could work. 
> So we created a patch.If you're sure it will never happen, then, of course, 
> skip it (and I'll have to work hard, because the quality department is 
> digging into everything).

Ok, but please don't send patches for such super theoretical problems found 
by some static analyzers. The QEMU project is already badly suffering from 
hundreds of AI-generated bug reports in the past months where we had to 
filter out a lot of AI slop, so please always make sure that a problem can 
also be really triggered before sending such a patch. Thanks!

  Thomas


> 15.09.2026 19:32, Thomas Huth пишет:
>> On 15/09/2026 18.17, Николай Зорин wrote:
>>> SWSA#4992cdf0-415c-45c1-be1a-71213467347d
>>>
>>> The `virtio_ccw_get_vdev()` function can return a `NULL` pointer if the
>>> corresponding subchannel driver data (`sch->driver_data`) is not initialized
>>> or has been cleared.
>>>
>>> If `vdev` is `NULL`, passing it directly into `virtio_queue_get_num(vdev, 
>>> vq_idx)`
>>> results in a `NULL` pointer dereference, which can lead to a hypervisor
>>> crash or unexpected termination of the QEMU process.
>>>
>>> Fix this by adding an explicit check for `!vdev` before verifying the
>>> queue index and its capacity, returning `-EINVAL` early if the device
>>> is missing or not bound to the subchannel.
>>>
>>> Signed-off-by: Nikolay N Zorin <zorin@swemel.ru>
>>> ---
>>>   hw/s390x/s390-hypercall.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/hw/s390x/s390-hypercall.c b/hw/s390x/s390-hypercall.c
>>> index ac1b08b2..fd2972c0 100644
>>> --- a/hw/s390x/s390-hypercall.c
>>> +++ b/hw/s390x/s390-hypercall.c
>>> @@ -44,7 +44,7 @@ static int handle_virtio_ccw_notify(uint64_t subch_id, 
>>> uint64_t data)
>>>       }
>>>
>>>       vdev = virtio_ccw_get_vdev(sch);
>>> -    if (vq_idx >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev, 
>>> vq_idx)) {
>>> +    if (!vdev || vq_idx >= VIRTIO_QUEUE_MAX || ! 
>>> virtio_queue_get_num(vdev, vq_idx)) {
>>>           return -EINVAL;
>>>       }
>>
>>  Hi!
>>
>> How did you trigger this problem? It should not exist anymore since:
>>
>> https://gitlab.com/qemu-project/qemu/-/commit/e5cb62e7b6f9
>>
>> which has been included since QEMU v10.2.
>>
>> So please provide some description how to reproduce it if it still happens 
>> with the latest version of QEMU.
>>
>>  Thanks,
>>   Thomas
>>
>> PS: The list of maintainers for the s390x part of QEMU also has recently 
>> been changed. Please use the MAINTAINERS file and scripts/ 
>> get_maintainer.pl from the latest version to check before sending patches. 
>> Thanks!
>>
> 

not AI, only (empty) brain :)

ok.

15.09.2026 19:50, Thomas Huth пишет:
> On 15/09/2026 18.42, Николай Зорин wrote:
>> This is the reaction of the (dynamic) static analyzer. We conducted 
>> research (at the request of the quality department) and found out 
>> that it could work. So we created a patch.If you're sure it will 
>> never happen, then, of course, skip it (and I'll have to work hard, 
>> because the quality department is digging into everything).
>
> Ok, but please don't send patches for such super theoretical problems 
> found by some static analyzers. The QEMU project is already badly 
> suffering from hundreds of AI-generated bug reports in the past months 
> where we had to filter out a lot of AI slop, so please always make 
> sure that a problem can also be really triggered before sending such a 
> patch. Thanks!
>
>  Thomas
>
>
>> 15.09.2026 19:32, Thomas Huth пишет:
>>> On 15/09/2026 18.17, Николай Зорин wrote:
>>>> SWSA#4992cdf0-415c-45c1-be1a-71213467347d
>>>>
>>>> The `virtio_ccw_get_vdev()` function can return a `NULL` pointer if 
>>>> the
>>>> corresponding subchannel driver data (`sch->driver_data`) is not 
>>>> initialized
>>>> or has been cleared.
>>>>
>>>> If `vdev` is `NULL`, passing it directly into 
>>>> `virtio_queue_get_num(vdev, vq_idx)`
>>>> results in a `NULL` pointer dereference, which can lead to a 
>>>> hypervisor
>>>> crash or unexpected termination of the QEMU process.
>>>>
>>>> Fix this by adding an explicit check for `!vdev` before verifying the
>>>> queue index and its capacity, returning `-EINVAL` early if the device
>>>> is missing or not bound to the subchannel.
>>>>
>>>> Signed-off-by: Nikolay N Zorin <zorin@swemel.ru>
>>>> ---
>>>>   hw/s390x/s390-hypercall.c | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/hw/s390x/s390-hypercall.c b/hw/s390x/s390-hypercall.c
>>>> index ac1b08b2..fd2972c0 100644
>>>> --- a/hw/s390x/s390-hypercall.c
>>>> +++ b/hw/s390x/s390-hypercall.c
>>>> @@ -44,7 +44,7 @@ static int handle_virtio_ccw_notify(uint64_t 
>>>> subch_id, uint64_t data)
>>>>       }
>>>>
>>>>       vdev = virtio_ccw_get_vdev(sch);
>>>> -    if (vq_idx >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev, 
>>>> vq_idx)) {
>>>> +    if (!vdev || vq_idx >= VIRTIO_QUEUE_MAX || ! 
>>>> virtio_queue_get_num(vdev, vq_idx)) {
>>>>           return -EINVAL;
>>>>       }
>>>
>>>  Hi!
>>>
>>> How did you trigger this problem? It should not exist anymore since:
>>>
>>> https://gitlab.com/qemu-project/qemu/-/commit/e5cb62e7b6f9
>>>
>>> which has been included since QEMU v10.2.
>>>
>>> So please provide some description how to reproduce it if it still 
>>> happens with the latest version of QEMU.
>>>
>>>  Thanks,
>>>   Thomas
>>>
>>> PS: The list of maintainers for the s390x part of QEMU also has 
>>> recently been changed. Please use the MAINTAINERS file and scripts/ 
>>> get_maintainer.pl from the latest version to check before sending 
>>> patches. Thanks!
>>>
>>
>

On Tue, Sep 15, 2026 at 08:00:45PM +0300, Николай Зорин wrote:
> not AI, only (empty) brain :)
> 
> ok.

I'm not saying the changes are bad as such. They just seem to need
more work, such as reproducing the issue and testing the fix.
Or maybe this was done, just not documented.

-- 
MST