CVE-2026-89981 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
arm64: Don't read GMID_EL1 when MTE is disabled
__cpuinfo_store_cpu() gates the GMID_EL1 read on the raw ID_AA64PFR1_EL1, so it reads the register even when the kernel has disabled MTE (CONFIG_ARM64_MTE=n or arm64.nomte). KVM sets HCR_EL2.TID5 in that case, and pKVM injects an UNDEF the host cannot handle:
Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP
pc : __cpuinfo_store_cpu+0xf4/0x264 Kernel panic - not syncing: Attempted to kill the idle task!
Only pKVM reaches it, and only after a CPU is offlined and brought back online: its CPU_ON relay sets the host HCR before the CPU enters EL1, while plain nVHE sets it at CPUHP_AP_KVM_ONLINE.
Gate the read on the CPU's own ID_AA64PFR1_EL1 with the command-line override applied, and on CONFIG_ARM64_MTE, which no register reflects. The boot CPU stores its registers before init_cpu_features() strips an unsafe override, so clamp against the hardware value here too.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel for ARM64 architectures contains a logic flaw in the __cpuinfo_store_cpu function that leads to system instability when Memory Tagging Extension (MTE) features are disabled via configuration or command-line parameters. The vulnerability arises because the code attempts to read the GMID_EL1 register regardless of whether MTE is actually enabled on the specific CPU core being initialized. This oversight creates a conflict with virtualization environments, particularly those utilizing pKVM, where the Hypervisor Configuration Register HCR_EL2 includes the TID5 bit set to trap accesses to certain system registers when MTE is not active in the guest or host context as determined by kernel configuration.
When MTE is disabled through CONFIG_ARM64_MTE being unset or via the arm64.nomte boot parameter, the kernel should logically avoid accessing hardware features associated with that extension. However, the existing implementation gates the GMID_EL1 read only on the raw value of ID_AA64PFR1_EL1 without accounting for these software-level overrides. Consequently, when a CPU is offlined and subsequently brought back online in a pKVM environment, the host HCR_EL2 register has already been configured to trap undefined instructions related to MTE registers. The subsequent attempt by __cpuinfo_store_cpu to read GMID_EL1 triggers an UNDEF exception that the kernel cannot handle within this context.
The operational impact of this flaw is severe, resulting in a critical system failure characterized by an Oops error indicating an undefined instruction with code 0x2000000 and ultimately leading to a Kernel panic stating Attempted to kill the idle task. This crash occurs specifically during CPU hotplug operations where CPUs are taken offline and then brought back online after pKVM has initialized its hypervisor state. The issue is isolated primarily to pKVM deployments because plain nVHE sets the relevant HCR bits at a different stage of the CPU online process, allowing it to avoid this specific race condition or configuration mismatch during initialization.
To resolve this vulnerability, the kernel logic must be updated to strictly gate the GMID_EL1 read operation based on both the actual hardware capability indicated by ID_AA64PFR1_EL1 and the effective MTE status derived from CONFIG_ARM64_MTE and command-line overrides. Since the boot CPU stores its register values before init_cpu_features() applies unsafe overrides, subsequent CPUs must clamp their checks against these finalized hardware values to ensure consistency. This ensures that no access is made to GMID_EL1 when MTE is effectively disabled by software configuration, thereby preventing the injection of unhandled UNDEF exceptions in virtualized environments and maintaining system stability during CPU state transitions.
From a security taxonomy perspective, this issue aligns with CWE-845 which relates to improper check for unusual or exceptional conditions, as the code fails to verify the effective feature availability before accessing hardware registers. It also reflects aspects of CWE-20 regarding Improper Input Validation where the software does not adequately validate configuration parameters against hardware capabilities prior to execution. In terms of attack vectors and behavior mapping under MITRE ATT&CK, this vulnerability represents a Denial of Service scenario specifically targeting system availability through resource management failures during CPU hotplug operations in virtualized infrastructure environments.