CVE-2022-50720 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
x86/apic: Don't disable x2APIC if locked
The APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC (or x2APIC). X2APIC mode is mostly compatible with legacy APIC, but it disables the memory-mapped APIC interface in favor of one that uses MSRs. The APIC mode is controlled by the EXT bit in the APIC MSR.
The MMIO/xAPIC interface has some problems, most notably the APIC LEAK [1]. This bug allows an attacker to use the APIC MMIO interface to
extract data from the SGX enclave.
Introduce support for a new feature that will allow the BIOS to lock the APIC in x2APIC mode. If the APIC is locked in x2APIC mode and the kernel tries to disable the APIC or revert to legacy APIC mode a GP fault will occur.
Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handle the new locked mode when the LEGACY_XAPIC_DISABLED bit is set by preventing the kernel from trying to disable the x2APIC.
On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX are enabled the LEGACY_XAPIC_DISABLED will be set by the BIOS. If legacy APIC is required, then it SGX and TDX need to be disabled in the BIOS.
[1]: https://aepicleak.com/aepicleak.pdf
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 04/20/2026
The vulnerability described in CVE-2022-50720 addresses a critical security issue within the Linux kernel's handling of Advanced Programmable Interrupt Controller (APIC) modes on x86 architectures. This flaw specifically relates to the interaction between the kernel's APIC management code and BIOS-level hardware configuration that can lock the APIC in x2APIC mode. The APIC supports two distinct operational modes: legacy APIC (xAPIC) and extended APIC (x2APIC), each with different memory mapping approaches and security implications. The x2APIC mode uses Model Specific Registers (MSRs) instead of memory-mapped interfaces, which fundamentally changes how interrupt handling occurs at the hardware level and impacts security boundaries.
The technical core of this vulnerability stems from the fact that the legacy xAPIC memory-mapped interface contains a known security flaw referred to as APIC LEAK, which was detailed in the research paper referenced in the CVE description. This vulnerability allows attackers to extract sensitive data from Intel Software Guard Extensions (SGX) enclaves through the APIC MMIO interface, creating a serious side-channel attack vector. The APIC LEAK vulnerability specifically enables unauthorized access to enclave memory through carefully crafted interrupt handling sequences that exploit the memory-mapped nature of the legacy APIC interface. This represents a direct violation of the security boundaries that SGX is designed to enforce.
The kernel implementation previously attempted to disable x2APIC mode by setting the EXT bit in the APIC MSR, but this approach failed to account for BIOS-level locking mechanisms that prevent such transitions. When the APIC is locked in x2APIC mode through BIOS configuration, attempting to revert to legacy APIC mode triggers a General Protection (GP) fault rather than silently failing. This behavior is implemented through a new MSR called IA32_XAPIC_DISABLE_STATUS, which provides kernel-level awareness of the APIC's locked state. The LEGACY_XAPIC_DISABLED bit within this MSR serves as a critical indicator that prevents kernel code from attempting invalid APIC mode transitions that would compromise system security. This mechanism directly addresses CWE-248, which covers "Uncaught Exception" scenarios where improper handling of locked hardware states leads to system instability and security breaches.
The operational impact of this vulnerability is significant for systems running Linux kernels that support Intel SGX and Trusted Domain Extensions (TDX) technologies. On platforms where these security features are enabled, the BIOS automatically sets the LEGACY_XAPIC_DISABLED bit to lock the APIC in x2APIC mode for security reasons. However, this creates a dependency issue where applications or system configurations requiring legacy APIC mode must either disable SGX and TDX in BIOS settings or accept the security implications of running with x2APIC mode locked. The vulnerability affects systems that may have been configured with legacy APIC requirements while also supporting modern security features, creating a compatibility and security conflict that requires careful BIOS-level configuration management. This aligns with ATT&CK technique T1059.003 for "Command and Scripting Interpreter: Windows Command Shell" in scenarios where system administrators need to modify BIOS settings to resolve security conflicts, though the specific attack surface relates more to hardware-level privilege escalation and memory access control.
The mitigation strategy involves updating the Linux kernel to properly handle the new IA32_XAPIC_DISABLE_STATUS MSR and the associated locked mode detection. System administrators should ensure their BIOS configurations align with their security requirements, particularly when running SGX or TDX workloads. The kernel now properly recognizes locked x2APIC modes and prevents invalid APIC mode transitions that could expose security boundaries or cause system instability. This vulnerability demonstrates the importance of maintaining proper hardware abstraction layers in kernel code and highlights how low-level hardware security features can create complex compatibility requirements that must be carefully managed through both firmware and operating system interfaces. The resolution effectively implements a security-by-design approach that prevents privilege escalation attacks targeting the APIC interface while maintaining system stability through proper error handling mechanisms.