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

Lukas Wunner <[email protected]>
Newsgroups gmane.linux.ports.ppc.embedded
Message-ID <apSdOnbdLdrJ7ksF__44949.4152142265$1788124493$gmane$org@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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.