CVE-2023-53438
Description
From CVE.org
In the Linux kernel, the following vulnerability has been resolved: x86/MCE: Always save CS register on AMD Zen IF Poison errors The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed. There is no architecturally-defined method to determine this behavior. The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCG_STATUS[EIPV|RIPV]. Add a quirk to save the CS register for poison consumption from the IF unit banks. This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is IN_KERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context.
Statement
On some AMD Zen systems, Instruction Fetch poison consumption can raise an MCE without EIPV/RIPV, causing the kernel to misidentify the context as kernel space (cs=0) and needlessly panic. The patch adds a Zen IFU quirk that always records CS for IF-bank (bank 1) poison errors, preventing incorrect severity grading and spurious panics. This is a reliability/availability fix tied to hardware error reporting (that is not a typical software-triggerable vulnerability). This issue cannot be triggered remotely or through software inputs. It depends on hardware-level memory poisoning (e.g., ECC errors or IFU poison events) on AMD Zen CPUs. Only physical attackers or test tools with MCE injection capabilities could reproduce it. The vulnerability primarily affects reliability by causing unnecessary kernel panics and does not provide any direct exploit path.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 4.2 | 5.5 | 5.5 |
| Attack Vector | Physical | Local | Local |
| Attack Complexity | High | Low | Low |
| Privileges Required | None | Low | Low |
| User Interaction | None | None | None |
| Scope | Unchanged | Unchanged | Unchanged |
| Confidentiality | None | None | None |
| Integrity Impact | None | None | None |
| Availability Impact | High | High | High |
Vector
Red Hat: CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
NVD: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
cve.org: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Understanding the Weakness (CWE)
Other
Technical Impact: Other
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
