Re: [PATCH v1] s390/virtio_ccw: Also suppress -EINVAL on device detach

[Halil Pasic <pasic@linux.ibm.com>]

On Fri, 12 Jun 2026 16:05:10 +0000
sashiko-bot@kernel.org wrote:

> [Severity: Critical]
> This is a pre-existing issue, but does this if/else structure create a
> use-after-free risk during virtqueue deletion?
> 
> If ccw_io_helper() fails with an error other than -ENODEV or -EINVAL
> (for example, -EIO), the first branch executes and logs the warning, but
> the 'else if' branch is entirely skipped.
> 
> This means virtio_ccw_drop_indicators() is never called, failing to clear
> the virtqueue pointers in the shared airq_info->aiv array.
> 
> Because virtio_ccw_del_vqs() subsequently proceeds to free these virtqueues
> via vring_del_virtqueue(), the uncleared pointers in the shared airq_info
> will point to freed memory.
> 
> If an adapter interrupt arrives later for this leaked bit, could
> virtio_airq_handler() retrieve the dangling pointer and trigger a
> use-after-free by calling vring_interrupt() on the freed queue?

Looks like this could be more robust against scenarios where we fail
to execute the channel program that is supposed to deregister the
indicators from the device.

The key question here is, at what point, can we consider adpter
interruption and event notification quiesced. I will have to do some
reading on that, I'm afraid. 

To me, it looks like just setting the virtqueue pointers in
airq_info->aiv would not do the trick either, because I don't see
a corresponding null pointer check.

Regards,
Halil