Re: [PATCH] KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic

[Matthew Rosato]

On 4/16/26 9:06 AM, Christian Borntraeger wrote:
> Am 15.04.26 um 11:26 schrieb Junrui Luo:
>> kvm_s390_pci_aif_enable(), kvm_s390_pci_aif_disable(), and
>> aen_host_forward() index the GAIT by manually multiplying the index
>> with sizeof(struct zpci_gaite).
>>
>> Since aift->gait is already a struct zpci_gaite pointer, this
>> double-scales the offset, accessing element aisb*16 instead of aisb.
>>
>> This causes out-of-bounds accesses when aisb >= 32 (with
>> ZPCI_NR_DEVICES=512)
>>
>> Fix by removing the erroneous sizeof multiplication.
>>
>> Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/
>> disabling interrupt forwarding")
>> Fixes: 73f91b004321 ("KVM: s390: pci: enable host forwarding of
>> Adapter Event Notifications")
>> Reported-by: Yuhao Jiang <danisjiang@xxxxxxxxx>
>> Cc: stable@xxxxxxxxxxxxxxx
>> Signed-off-by: Junrui Luo <moonafterrain@xxxxxxxxxxx>
> 
> looks good to me.
> Reviewed-by: Christian Borntraeger <borntraeger@xxxxxxxxxxxxx>
> 
> Out of interest, was this found by static code checking or AI by any
> chance?
> 
> 
> 
> @Matt, can you test/review this as well?
> 

Thanks for the report and the fix.

I did some tracing to confirm the issue -- indeed, gaite is being
indexed by 256B instead of 16B.

Because the incorrect offset calculation was used consistently in all 3
spots, the expected gaite is always found; a problem only arises once we
attempt to access beyond the allocated number of pages for the gaite array.

When this can possibly happen is a factor of the configurable
CONFIG_PCI_NR_FUNCTIONS -- but yes, as the commit message alludes to,
the default for this is 512 which means once aisb reaches 32 * 256B we
would cross beyond the 2 contiguous 4K pages that would have been
allocated for 512 * 16B entries.

I also did some general regression testing with a mixture of ISM, mlx
and NVMe devices with this patch applied.

Reviewed-by: Matthew Rosato <mjrosato@xxxxxxxxxxxxx>
Tested-by: Matthew Rosato <mjrosato@xxxxxxxxxxxxx>