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

CVSS 5.5CVE-2025-40034Kernel, userspace & hypervisorcurated

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

https://git.kernel.org/stable/c/41683624cbff0a26bb7e0627f4a7e1b51a8779a8 https://git.kernel.org/stable/c/deb2f228388ff3a9d0623e3b59a053e9235c341d https://nvd.nist.gov/vuln/detail/CVE-2025-40034

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.