Re: [PATCH v6 09/15] s390/vfio-ap: Add method to set a new guest AP configuration

Anthony Krowiak <[email protected]> Wed, 5 Aug 2026 08:15:30 -0400
Newsgroups dev.linux.lists.sashiko-reviews,org.kernel.vger.kvm,org.kernel.vger.linux-s390
Message-ID <[email protected]>

On 7/27/26 2:11 PM, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Latent NULL pointer dereference in `collect_queues_by_apid` due to contradictory logic.
> --
>
> --- Patch [9]: [PATCH v6 09/15] s390/vfio-ap: Add method to set a new guest AP configuration ---
> commit 5b979f09ef9429e09eace5977dabbd22cc832bbf
> Author: Anthony Krowiak <[email protected]>
>
> s390/vfio-ap: Add method to set a new guest AP configuration
>
> This commit adds a new vfio_ap_set_new_config function to set a guest's AP
> configuration. It refactors code from ap_config_store to handle changes to
> the sysfs ap_config attribute and support live guest migration.
>
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
>> index d05372b50d2fc..0b49be22d5d8b 100644
>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> [ ... ]
>
>> -static void collect_queues_to_reset(struct ap_matrix_mdev *matrix_mdev,
>> -				    unsigned long apid,
>> -				    struct list_head *qlist)
>> +static void collect_queues_by_apid(struct ap_matrix_mdev *matrix_mdev,
>> +				   unsigned long apid,
>> +				   struct list_head *qlist)
>>   {
>>   	struct vfio_ap_queue *q;
>>   	unsigned long  apqi;
>>   
>>   	for_each_set_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm, AP_DOMAINS) {
>> -		q = vfio_ap_mdev_get_queue(matrix_mdev, AP_MKQID(apid, apqi));
>> +		q = matrix_mdev ?
>> +				vfio_ap_mdev_get_queue(matrix_mdev, AP_MKQID(apid, apqi)) :
>> +				vfio_ap_find_queue(AP_MKQID(apid, apqi));
> [Severity: Medium]
> Will this result in a NULL pointer dereference if matrix_mdev is NULL?
>
> The loop condition unconditionally accesses matrix_mdev->shadow_apcb.aqm.
> However, the ternary operator inside the loop (matrix_mdev ?) suggests
> that matrix_mdev could be NULL.
>
> If matrix_mdev can indeed be NULL, the unconditional dereference in
> for_each_set_bit_inv() will crash before the check is evaluated. If
> matrix_mdev is never NULL in practice, is the ternary check necessary?

Every caller passes matrix_mdev obtained from container context that is
always non-NULL at those call sites. The ternary is dead code — matrix_mdev
is never NULL here and will be removed.

>
>>   		if (q)
>>   			list_add_tail(&q->reset_qnode, qlist);
>>   	}