Red Hat response to Intel and AMD CPU vulnerabilities (CVEs CVE-2021-46778, CVE-2022-21233, CVE-2022-26373)

Solution In Progress - Updated -

Environment

  • Red Hat Enterprise Linux
  • AMD and Intel CPUs

Issue

Security researchers continue to discover vulnerabilities in hardware systems. In this KCS we disclose three unrelated security vulnerabilities in both Intel, AMD and other hardware companies.

CVE-2022-21233 is also known as AEPIC Leak.

Resolution

Red Hat is aware of these processor issues, have ranked them as Moderate severity and will be providing kernel mitigations in an upcoming release for the affected kernels, following the Life Cycle phases.
Please subscribe to the below CVE pages for updates and fix availability:

Mitigations

  • CVE-2021-46778: AMD recommends using constant-time algorithms in cryptographically sensitive code to avoid secret-dependent control flow in software development. There are no operating system specific mitigations available.

  • CVE-2022-21233: Enable x2apic in the system BIOS/ UEFI configuration or disable "Legacy APIC" as it is called in some BIOS/ system configurations. Intel has provided additional microcode updates for systems using SGX along with advice on how to implement mitigations in software.

  • CVE-2022-26373: There are no known mitigations at this time, software packages will be provided when available. Please refer to Intel Documentation for additional technical information.

Root Cause

CVE-2021-46778
This flaw relies on a hardware side channel found in AMD CPU architectures. An attacker can measure the contention level on scheduler queues in the processor microarchitecture, possibly leading to the potential leak of sensitive information. This contention-based side-channel attack may allow an attacker who is able to execute code on sibling cores to leak secrets such as cryptographic keys from co-located workloads on sibling hardware threads.

This affects the AMD CPU architectures codenamed Zen 1, Zen 2 and Zen 3 based hardware.

CVE-2022-21233
The Advanced Programmable Interrupt Controller (APIC) is an integrated CPU component responsible for accepting, prioritizing, and dispatching interrupts to logical processors (LPs).

The APIC can operate in xAPIC mode (also known as legacy mode) in which APIC configuration registers are exposed through a memory-mapped I/O (MMIO) page.

An attacker able to execute code on a target CPU is able to query the APIC configuration page. When reading the APIC configuration page with an unaligned read from the MMIO page, the registers may return stale data from previous requests made by the same processor core to the same configuration page.

Note: Naturally aligned 8-byte loads or APIC virtualization are not affected. This behavior only applies to access to the physical xAPIC MMIO page.

Intel recommends that operating systems and virtual machine monitors (VMMs) enable x2APIC mode, which disables the xAPIC MMIO page and instead exposes APIC registers through model-specific registers (MSRs) mitigates the issue.

Enabling the x2apic (when available) is usually default and achieved in the system's firmware configuration utility or BIOS. It can be enabled by entering the system boot configuration and setting the system APIC mode appropriately.

Boot log messages can show which APIC mode is enabled, for example:

$ dmesg |grep "x2apic enabled"
[    0.304688] x2apic enabled

CVE-2022-26373
Modern processors have included Enhanced Indirect Branch Restricted Speculation features (eIBRS) in an attempt to mitigate Branch Target Prediction attacks. Systems that use eIBRS instead of other mitigation methods such as retpoline are vulnerable to return buffer correction attacks after the intended protection barriers.

The Return Stack Buffer (RSB) is a microarchitectural structure that holds predicted targets of near RET instructions. This allows the CPU to guess a return ‘target’ and continue to execute code speculatively to improve system performance.

A local attacker can create a situation where a specifically crafted sequence of assembly instructions could trigger speculation on the wrong path based on default behavior in the RSB microarchitecture. This sequence of instructions could occur in existing code where a function returns (RET) without a prior corresponding call instruction that is executed after the vm exit instruction.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.