Re: [PATCH v2 6/8] s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap

[Anthony Krowiak <akrowiak@linux.ibm.com>]

On 8/11/26 2:02 PM, Matthew Rosato wrote:
> On 8/10/26 3:22 PM, Anthony Krowiak wrote:
>> The DECLARE_BITMAP(apm_filtered, AP_DEVICES) macro allocates the bitmap
>> on the stack without zero-initializing it.
>>
>> In vfio_ap_mdev_hot_plug_cfg(), the vfio_ap_mdev_filter_matrix() function
>> is only called to initialize and populate apm_filtered if either
>> filter_adapters or filter_domains is true. If the hot plug configuration
>> change only adds control domains (meaning filter_cdoms is true, but
>> filter_adapters and filter_domains are both false),
>> vfio_ap_mdev_filter_matrix() is bypassed.
>>
>> Consequently, apm_filtered is passed to reset_queues_for_apids() with
>> uninitialized stack garbage. This can cause reset_queues_for_apids() to
>> interpret arbitrary stack garbage bits as valid APIDs to reset, potentially
>> performing unintended guest hardware queue resets.
>>
>> Fix this by zero-initializing the apm_filtered bitmap at the beginning of
>> vfio_ap_mdev_hot_plug_cfg() using bitmap_zero().
>>
>> Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
> Sashiko mentions an unrelated, pre-existing issue with cfg_chg_trigger
> that does not appear to be resolved by this series; please have a look.

I vaguely recall that, but my head is spinning dealing with the plethora of
hades review comments addressing pre-existing issues and it got lost in
the melee. I'll hunt for it.

>
> You do not necessarily need to add another fix to this series, it could
> be a follow-on.
>
> As for this patch:
>
> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
>
>