Bug 1810359 (CVE-2020-0550)
| Summary: | CVE-2020-0550 hw: Snoop-Assisted L1D Sampling | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Wade Mealing <wmealing> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | acaringi, bhu, brdeoliv, dhoward, dvlasenk, fhrbata, gmollett, hkrzesin, jlelli, jshortt, jstancek, kernel-mgr, lgoncalv, nmurray, qzhao, rvrbovsk, security-response-team, williams |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: |
A flaw was found in the Intel CPU's cache coherency mechanism. A microarchitectural (hardware) implementation issue that could allow an unprivileged local attacker to bypass conventional system security controls to infer on-CPU Level 1 cache contents is present. At this time, this specific flaw is only known to affect Intel-based processors. The highest threat from this vulnerability is to data confidentiality.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-10 22:31:49 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1753462 | ||
|
Description
Wade Mealing
2020-03-05 04:25:40 UTC
Affected CPU releases: - Legacy Intel Core Processors (Sandy Bridge) - Intel Xeon Processor family v2 (Sandy Bridge) - Intel Xeon Processor family v3 (Haswell) - Intel Xeon Processor family v4 (Broadwell) This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-0550 External References: https://software.intel.com/security-software-guidance/insights/deep-dive-introduction-speculative-execution-side-channel-methods https://software.intel.com/security-software-guidance/software-guidance https://software.intel.com/security-software-guidance/insights https://access.redhat.com/articles/snoop-assisted-l1d-sampling Statement: CVE-2020-0550 is the CVE assigned specifically to the hardware implementation leading to this flaw. Unlike the L1TF microarchitectural issue, no additional CVE have been assigned at this time to cover operating systems or vmm/hypervisor specific implementations. As this CVE is a flaw in specific hardware, not the operating system kernel, and operating system mitigations are already applied, Red Hat does not list the Red Hat Enterprise Linux kernel package as “affected” by this CVE. This does not imply that the flaw can not be exposed on systems running Red Hat Enterprise Linux on vulnerable hardware, only that the flaw exists in the hardware implementation and no additional changes are deemed necessary or practical to address this flaw at the software layer. Existing mitigations released in Red Hat Enterprise Linux in response to Spectre V1 (https://access.redhat.com/security/vulnerabilities/speculativeexecution), L1TF (https://access.redhat.com/security/vulnerabilities/L1TF) and MDS (https://access.redhat.com/security/vulnerabilities/mds) should already provide significant barrier against exploitation of this attack vector and no new mitigation is planned at this time. Mitigation: Due to the high level of difficulty of the attack and the performance impact which would be associated with any potential mitigations, there are currently no microcode or software mitigations for this issue, other than the existing L1TF mitigations described above, which protect virtual machines against other virtual machines on the host; and disabling TSX, as described above, which can raise the bar of difficulty of the attack. Red Hat doesn't currently have knowledge of any real-world occurrences of this attack, so the risk of attack may be considered low. To further minimize the possibility of attacks related to this and other speculative issues, trusted and untrusted workloads can be isolated on separate systems. |