Re: [PATCH v1 5/5] x86/cpu: Don't reset boot CPU cpuinfo in identify_cpu()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The patch deliberately leaves 32-bit systems vulnerable to the exact same interrupt window race condition that it fixes for 64-bit systems.
--

commit 7225f9ebac0ba182d1da83ea9f37319d7bdecfdb
Author: Ihor Solodrai <ihor.solodrai@linux.dev>

x86/cpu: Don't reset boot CPU cpuinfo in identify_cpu()

This patch moves the init_cpu_info() call out of identify_cpu() into its
callers and skips it for the boot CPU on 64-bit systems. This prevents a window
where interrupts can observe cleared CPU capabilities. 32-bit systems still
reset capabilities in identify_boot_cpu() to maintain the no-CPUID default.

Link: https://lore.kernel.org/bpf/20260610175651.647515-1-ihor.solodrai@linux.dev/

> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 93ad02ceacc24..01d07b1f30788 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c

[ ... ]

> @@ -2156,6 +2154,13 @@ static void identify_cpu_32(struct cpuinfo_x86 *c)
>  
>  static __init void identify_boot_cpu(void)
>  {
> +	/*
> +	 * The boot CPU's capabilities were already scanned in early_identify_cpu().
> +	 * However 32-bit still needs to init_cpu_info() here for the no-CPUID
> +	 * cpuid_level default.
> +	 */
> +	if (IS_ENABLED(CONFIG_X86_32))
> +		init_cpu_info(&boot_cpu_data);

[Severity: High]
This is a pre-existing issue, but does leaving the call to init_cpu_info() here
leave 32-bit systems vulnerable to the exact same interrupt window race condition
that this patch fixes for 64-bit?

Because start_kernel() calls local_irq_enable() before arch_cpu_finalize_init()
calls identify_boot_cpu(), an interrupt can fire immediately after
init_cpu_info() clears the capabilities:

arch/x86/kernel/cpu/common.c:init_cpu_info() {
    ...
    memset(&c->x86_capability, 0, sizeof(c->x86_capability));
    ...
}

If a timer tick or other hardware interrupt fires right after this memset,
and the interrupt handler dynamically evaluates boot_cpu_has(), won't it
falsely observe missing capabilities and potentially cause a crash or
incorrect behavior during boot?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260704002046.3859585-1-ihor.solodrai@linux.dev?part=5