Re: [PATCH v3] arm64: Don't read GMID_EL1 when MTE is disabled

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Kernel panic on non-MTE hardware caused by unsanitized command-line overrides in gmid_el1_accessible().
--

--- Patch [1]: [PATCH v3] arm64: Don't read GMID_EL1 when MTE is disabled ---
commit ff2144eb5268c6bf4e244c7063fffca15d574919
Author: Fuad Tabba <fuad.tabba@linux.dev>

arm64: Don't read GMID_EL1 when MTE is disabled

This patch prevents __cpuinfo_store_cpu() from reading the GMID_EL1 register
when MTE is disabled, avoiding a host panic when pKVM injects an UNDEF. It
introduces a new helper to check if MTE is accessible by evaluating both
CONFIG_ARM64_MTE and the raw ID_AA64PFR1_EL1 combined with command-line
overrides.

Cc: stable@vger.kernel.org

> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index d90040fb9de6c..aaf267c7eb243 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
[ ... ]
> @@ -1085,6 +1085,21 @@ static inline bool cpu_has_lpa2(void)
>  #endif
>  }
>  
> +/*
> + * Reading GMID_EL1 when the kernel has disabled MTE traps to EL2, and the raw
> + * ID_AA64PFR1_EL1 reflects neither CONFIG_ARM64_MTE nor the cmdline override.
> + */
> +static inline bool gmid_el1_accessible(u64 pfr1)
> +{
> +	if (!IS_ENABLED(CONFIG_ARM64_MTE))
> +		return false;
> +
> +	pfr1 &= ~id_aa64pfr1_override.mask;
> +	pfr1 |= id_aa64pfr1_override.val;
> +
> +	return id_aa64pfr1_mte(pfr1);
> +}

[Severity: High]
Does this manual application of the command-line override bypass the standard
feature sanitization?

If a user specifies a command-line override to explicitly enable MTE on
hardware that does not natively support it (e.g., id_aa64pfr1.mte=1), this
code applies the raw id_aa64pfr1_override directly.

Normally, the cpufeature framework uses arm64_ftr_safe_value() to drop unsafe
overrides that attempt to enable unimplemented hardware features. Because this
function skips that sanitization, it will return true for an invalid override,
leading to an UNDEF exception and kernel panic when __cpuinfo_store_cpu()
subsequently attempts to read the unallocated GMID_EL1 register.

Could this check be adjusted to use a sanitized value or ensure unsafe
overrides are safely ignored?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260824184155.2644646-1-fuad.tabba@linux.dev?part=1