Re: [PATCH v5 2/8] um: Check for missing AVX and AVX-512 xstate bits

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incomplete XCR0 validation whitelist allows dependent AVX/AVX-512/AMX features to bypass xstate checks.
--

commit e378386cb877bae1a24be0e8bda74c90d72f4636
Author: Eric Biggers <ebiggers@kernel.org>

um: Check for missing AVX and AVX-512 xstate bits

This commit introduces a check in the UML architecture to verify that all
corresponding bits are set in the XCR0 register for AVX and AVX-512 support.
If any bits are missing, the features are disabled and a warning is issued.
This aligns UML behavior with userspace by ensuring xstate support before using
advanced CPU features.

> diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
> index e4ee693961e4e..9d53cc6a783d7 100644
> --- a/arch/um/kernel/um_arch.c
> +++ b/arch/um/kernel/um_arch.c

[ ... ]

> +static void __init validate_and_set_cpu_cap(int cap, u64 xcr0)
> +{
> +	/*
> +	 * Check for missing xstate features right away, so that there's no
> +	 * perceived need for all optimized code in the kernel to do so.
> +	 */
> +	switch (cap) {
> +	case X86_FEATURE_AVX:

[ ... ]

> +	case X86_FEATURE_AVX512_VPOPCNTDQ:
> +		if ((xcr0 & 0xe7) != 0xe7) {
> +			static bool warned;
> +
> +			if (!warned) {
> +				os_warn("Disabling AVX-512 support due to missing xstate features\n");
> +				warned = true;
> +			}
> +			return;
> +		}
> +		break;
> +	}

[Severity: Medium]
Does this switch statement omit validation for several AVX and AMX dependent
features?

Because this acts as a manual whitelist, features like F16C, FMA4, XOP,
AMX_TILE, and AMX_INT8 appear to fall through the switch statement and bypass
xstate validation entirely.

If the host disabled AVX/AMX in XCR0 but the hardware supports it (and still
advertises the dependent features in /proc/cpuinfo), they would fall through
and be unconditionally enabled here.

If kernel code or userspace checks these omitted flags, could it attempt to
execute unsupported instructions and trigger a #UD fault?

> +	set_cpu_cap(&boot_cpu_data, cap);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901145740.42337-1-ebiggers@kernel.org?part=2