Linux kernel (drivers/pci/pcie): AER's rate limiter dereferences per-device error state without checking it exists.

Impact

AER's rate limiter dereferences per-device error state without checking it exists. When firmware reports an error against a device that has no AER capability, that state is NULL and the node panics inside the error-handling worker - the machine dies while processing an error report rather than logging it.

Who can reach it

Reached through the ACPI APEI/GHES path: platform firmware reports a hardware error and names a source device that does not advertise an AER capability. The upstream crash names an Intel Sky Lake-E DMI device - i.e. a root-complex-internal device on a mainstream server chipset, so the affected hardware is ordinary datacenter silicon, not embedded. The error events that make this path run come from real PCIe traffic, which on a passthrough node includes a tenant driving its own GPU or NIC into generating errors; the tenant does not choose which device firmware blames, so treat this as device/firmware-driven rather than precisely targetable.

What to do

Update to a kernel carrying the fix (no fixed_in published; stable commits below). Interim: on affected Intel server platforms, check whether firmware-first error handling (GHES) is enabled in BIOS and consider native AER handling instead, and monitor GHES-reported corrected-error rates.

References