CVE-2025-40034
Awaiting Analysis Awaiting Analysis - Queue
BaseFortify

Publication date: 2025-10-28

Last updated on: 2025-10-30

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: PCI/AER: Avoid NULL pointer dereference in aer_ratelimit() When platform firmware supplies error information to the OS, e.g., via the ACPI APEI GHES mechanism, it may identify an error source device that doesn't advertise an AER Capability and therefore dev->aer_info, which contains AER stats and ratelimiting data, is NULL. pci_dev_aer_stats_incr() already checks dev->aer_info for NULL, but aer_ratelimit() did not, leading to NULL pointer dereferences like this one from the URL below: {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0 {1}[Hardware Error]: event severity: corrected {1}[Hardware Error]: device_id: 0000:00:00.0 {1}[Hardware Error]: vendor_id: 0x8086, device_id: 0x2020 {1}[Hardware Error]: aer_cor_status: 0x00001000, aer_cor_mask: 0x00002000 BUG: kernel NULL pointer dereference, address: 0000000000000264 RIP: 0010:___ratelimit+0xc/0x1b0 pci_print_aer+0x141/0x360 aer_recover_work_func+0xb5/0x130 [8086:2020] is an Intel "Sky Lake-E DMI3 Registers" device that claims to be a Root Port but does not advertise an AER Capability. Add a NULL check in aer_ratelimit() to avoid the NULL pointer dereference. Note that this also prevents ratelimiting these events from GHES. [bhelgaas: add crash details to commit log]
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-28
Last Modified
2025-10-30
Generated
2026-05-07
AI Q&A
2025-10-28
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Currently, no data is known.
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a NULL pointer dereference in the Linux kernel's PCI/AER subsystem, specifically in the aer_ratelimit() function. When platform firmware provides error information via ACPI APEI GHES, it may reference a device that does not advertise an AER Capability, causing dev->aer_info to be NULL. While pci_dev_aer_stats_incr() checks for this NULL, aer_ratelimit() did not, leading to a NULL pointer dereference and potential kernel crash. The fix adds a NULL check in aer_ratelimit() to prevent this issue.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to crash due to a NULL pointer dereference when handling hardware error reports from certain devices. This can lead to system instability or downtime, especially on systems using affected hardware and firmware error reporting mechanisms.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring kernel logs for NULL pointer dereference errors related to aer_ratelimit() and PCI/AER hardware error messages from the ACPI APEI GHES mechanism. Look for messages similar to: "BUG: kernel NULL pointer dereference, address: ... RIP: ... ratelimit" and hardware error logs indicating devices that do not advertise AER Capability but generate error reports. Commands to check kernel logs include: `dmesg | grep -i aer`, `journalctl -k | grep -i aer`, or `dmesg | grep -i 'NULL pointer dereference'`.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version where the NULL pointer check in aer_ratelimit() has been added, as this patch prevents the NULL pointer dereference. Until the update is applied, monitoring and possibly disabling problematic PCI devices that do not advertise AER Capability but generate errors may reduce crashes. Additionally, ensure platform firmware is up to date to minimize erroneous error reports.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart