Re: [PATCH] PCI/AER: Fix struct pci_dev reference leak in aer_process_err_devices()

[Lukas Wunner <lukas@wunner.de>]

On Sun, Aug 30, 2026 at 08:28:28PM +0000, Priyank Rathod wrote:
> If is_error_source() matches a device purely by Requester/Completer ID
> match (e_info->id == pci_dev_id(dev)), the device is added to e_info->dev[]
> even if it lacks the AER extended capability (dev->aer_cap == 0).

Hallucination, we do not enable error reporting on devices without
AER capability, see pci_aer_init().

> Later, during aer_process_err_devices(), aer_get_device_error_info()
> returns 0 when dev->aer_cap is 0 (or if no active error status is read),

The "no active error status is read" is the only scenario where
this *could* happen.  However if no error bits are set in the
status register, why did the device send an error message upstream
in the first place?  That would be a broken device.

Another theoretical possibility would be that the device becomes
inaccessible by the time aer_get_device_error_info() reads the
status/mask registers.  They'd both be read as "all ones",
hence info->status & ~info->mask == 0.

> On the ID-match fast path (a), is_error_source() returns true without
> checking whether the device implements the AER extended capability
> (dev->aer_cap != 0). This creates a real, non-exotic situation in several
> common hardware topologies and operational states:

Hallucination, this is by no means "real, non-exotic",
it's an unlikely corner case.

Thanks,

Lukas