All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eric Biggers" <ebiggers@kernel.org>
Cc: linux-raid@vger.kernel.org, yukuai@fygo.io
Subject: Re: [PATCH v2 2/8] um: Check for missing AVX and AVX-512 xstate bits
Date: Tue, 28 Jul 2026 02:37:33 +0000	[thread overview]
Message-ID: <20260728023733.C1EC81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260728021603.79870-3-ebiggers@kernel.org>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Incomplete XCR0 validation whitelist allows AVX-dependent and AMX features to bypass state checks, causing guest application crashes.

Pre-existing issues:
- [High] Substring matching flaw in `parse_host_cpu_flags()` incorrectly enables CPU features, leading to application crashes.
--

--- Patch [2]: [PATCH v2 2/8] um: Check for missing AVX and AVX-512 xstate bits ---
commit 14fa8af6eb070800589e8e98d9a0ba3804acb926
Author: Eric Biggers <ebiggers@kernel.org>

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

This patch checks if the CPU declares AVX or AVX-512 support and verifies
that the corresponding bits are set in the XCR0 register. If missing, it
warns and does not set the X86_FEATURE_* flags.

> diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
> index 2141f5f1f5a20..aafbaef2ae82f 100644
> --- a/arch/um/kernel/um_arch.c
> +++ b/arch/um/kernel/um_arch.c
[ ... ]
> @@ -264,12 +264,88 @@ unsigned long brk_start;
[ ... ]
> +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_AVX2:

[Severity: High]
Will this switch statement inadvertently bypass state checks for features like
X86_FEATURE_AMX_TILE, X86_FEATURE_F16C, X86_FEATURE_XOP, and
X86_FEATURE_FMA4?

If these features are missing from the switch cases, they will fall through
and be unconditionally enabled at the end of the function. If the host CPU
supports AMX, UML will advertise amx_tile. If a guest application attempts
to use it without the UML process calling prctl(ARCH_REQ_XCOMP_PERM), the
host will send SIGILL.

A similar #UD crash could occur for f16c, fma4, or xop if host AVX XCR0
state is disabled but the features are not cleared by the host.

> +	case X86_FEATURE_AVX_VNNI:
> +	case X86_FEATURE_FMA:
[ ... ]
> +		break;
> +	}
> +	set_cpu_cap(&boot_cpu_data, cap);
> +}
> +
>  static void __init parse_host_cpu_flags(char *line)
>  {
> +	u64 xcr0 = read_xcr0();
>  	int i;
> +
>  	for (i = 0; i < 32*NCAPINTS; i++) {
>  		if ((x86_cap_flags[i] != NULL) && strstr(line, x86_cap_flags[i]))
> -			set_cpu_cap(&boot_cpu_data, i);
> +			validate_and_set_cpu_cap(i, xcr0);

[Severity: High]
This is a pre-existing issue, but does this substring match cause false
positive feature detection?

Using strstr without word boundary checks means that if a host CPU supports
fma4 but not fma (like AMD Bulldozer), the string "fma" will match inside
"fma4".

This causes UML to falsely advertise fma to the guest, and guest
applications probing for fma will reliably crash with a #UD exception when
attempting to execute FMA3 instructions.

>  	}
>  }

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

  reply	other threads:[~2026-07-28  2:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  2:15 [PATCH v2 0/8] x86: Remove cpu_has_xfeatures() and add AVX-512 xor_gen() Eric Biggers
2026-07-28  2:15 ` [PATCH v2 1/8] x86/fpu: Check for missing AVX and AVX-512 xstate bits Eric Biggers
2026-07-28  5:27   ` Borislav Petkov
2026-07-28  5:45     ` Eric Biggers
2026-07-28  9:23     ` David Laight
2026-07-28  2:15 ` [PATCH v2 2/8] um: " Eric Biggers
2026-07-28  2:37   ` sashiko-bot [this message]
2026-07-28  2:15 ` [PATCH v2 3/8] crypto: x86 - Stop using cpu_has_xfeatures() Eric Biggers
2026-07-28  9:30   ` David Laight
2026-07-28  2:15 ` [PATCH v2 4/8] lib/crypto: x86: " Eric Biggers
2026-07-28  2:16 ` [PATCH v2 5/8] lib/crc: " Eric Biggers
2026-07-28  2:16 ` [PATCH v2 6/8] x86/fpu: Remove cpu_has_xfeatures() Eric Biggers
2026-07-28  2:16 ` [PATCH v2 7/8] lib/raid/xor: x86: Remove redundant X86_FEATURE_OSXSAVE check Eric Biggers
2026-07-28  3:41   ` Christoph Hellwig
2026-07-28  2:16 ` [PATCH v2 8/8] lib/raid/xor: x86: Add AVX-512 optimized xor_gen() Eric Biggers
2026-07-28  3:44   ` Christoph Hellwig
2026-07-28  3:44 ` [PATCH v2 0/8] x86: Remove cpu_has_xfeatures() and add AVX-512 xor_gen() Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260728023733.C1EC81F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yukuai@fygo.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.