Re: [PATCH v3 4/8] s390/pci: Fix use-after-free race in zpci floating interrupt cleanup

["Tobias Schumacher" <ts@linux.ibm.com>]

On Fri Oct 9, 2026 at 8:32 AM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] s390/pci: pending directed MSIs cause spurious interrupts on reallocation
> --
>
> commit 125383b5f8790de7f1cbeff916db7b71f9226ee6
> Author: Tobias Schumacher <ts@linux.ibm.com>
>
> s390/pci: Fix use-after-free race in zpci floating interrupt cleanup
>
> This commit splits directed vectors from floating vectors into a separate
> zpci_dibv array and adds RCU synchronization to zpci_msi_teardown_floating()
> to prevent use-after-free issues. It also annotates zpci_ibv with __rcu to
> ensure safe access to floating vectors during teardown.
>
>> diff --git a/arch/s390/pci/pci_irq.c b/arch/s390/pci/pci_irq.c
>> index d5763c5feb097..c5fabad381395 100644
>> --- a/arch/s390/pci/pci_irq.c
>> +++ b/arch/s390/pci/pci_irq.c
> [ ... ]
>> @@ -342,13 +343,16 @@ static struct airq_struct zpci_airq = {
>>
>>  static void zpci_msi_teardown_directed(struct zpci_dev *zdev)
>>  {
>> -	airq_iv_free(zpci_ibv[0], zdev->msi_first_bit, zdev->msi_nr_irqs);
>> +	airq_iv_free(zpci_dibv[0], zdev->msi_first_bit, zdev->msi_nr_irqs);
>
> [Severity: High]
> Does this code leave pending DMA bits on remote CPUs intact?
>
> Only CPU 0's vector is passed to airq_iv_free() here, which clears the
> physical vector bits on CPU 0 but leaves them untouched on remote CPUs.
>
> If a hardware adapter interrupt was pending on a remote CPU in
> zpci_dibv[N]->vector, the bit remains set. Furthermore, there is no
> synchronization (such as synchronize_rcu() or draining) to ensure remote
> CPUs have finished processing the old bit before it is freed.
>
> When a new device allocates the same MSI bit, it will overwrite the ptr and
> data fields across all CPUs without memory barriers. If a remote CPU then
> processes its delayed interrupt, it will read the newly populated ptr and
> data, resulting in a spurious interrupt delivered to the wrong device or a
> potential kernel panic from an inconsistent domain/hwirq pair.

The only change this patch makes to zpci_msi_teardown_directed() is the
rename from zpci_ibv to zpci_dibv. Freeing the directed bits only in
CPU 0's vector goes back to the original commit introducing directed
interrupts. A stale bit on a remote CPU could in theory end up as a
spurious interrupt for a device that later gets the same bit, but until
the bit is reused, the cleared pointer makes the lookup fail harmlessly.

I'll have a look at clearing the bits on all CPUs separately from this
series.

Thanks
Tobias