A warning can be triggered when a CPU feature is cleared after alternatives have been patched. This can happen if a privileged user modifies architectural MSRs (like MSR_IA32_MISC_ENABLE) from userspace and then hotplugs a CPU. This creates an inconsistent SMP state where a secondary CPU lacks a feature that the boot CPU had. The warning looks like this: ------------[ cut here ]------------ alternatives_patched WARNING: arch/x86/kernel/cpu/cpuid-deps.c:127 at do_clear_cpu_cap+0x416/0x450 arch/x86/kernel/cpu/cpuid-deps.c:127, CPU#1: swapper/1/0 Call Trace: early_init_intel+0xb3d/0xea0 arch/x86/kernel/cpu/intel.c:309 init_intel+0x28/0x780 arch/x86/kernel/cpu/intel.c:528 identify_cpu+0xc7a/0x3660 arch/x86/kernel/cpu/common.c:2053 identify_secondary_cpu+0xaa/0x160 arch/x86/kernel/cpu/common.c:2177 ap_starting+0x9c/0x150 arch/x86/kernel/smpboot.c:190 start_secondary+0x66/0x110 arch/x86/kernel/smpboot.c:280 common_startup_64+0x13e/0x157 WARN_ON() must not be used for conditions that can legitimately happen, such as a privileged user modifying MSRs or a broken BIOS. Replace the WARN_ON() with a pr_err() that logs a clear error message indicating that a CPU feature was cleared late, and explicitly prints the name of the feature being cleared to provide better context. To achieve this, move the x86_feature_name() helper function higher up in arch/x86/kernel/cpu/cpuid-deps.c so it can be utilized inside do_clear_cpu_cap(). Fixes: ee8962082a44 ("x86/alternatives: Catch late X86_FEATURE modifiers") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+907f82f5bbbf4a0d89fc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=907f82f5bbbf4a0d89fc Link: https://syzkaller.appspot.com/ai_job?id=c3c1fb43-1c46-43f9-9819-b9e6b7d3e0b4 To: "Borislav Petkov" To: "Dave Hansen" To: To: "Ingo Molnar" To: "Thomas Gleixner" To: Cc: "Babu Moger" Cc: "Elena Reshetova" Cc: "H. Peter Anvin" Cc: "Reinette Chatre" Cc: "Sohil Mehta" Cc: "Tom Lendacky" --- diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index 99801e844..a7c57cc81 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -114,6 +114,21 @@ static inline void clear_feature(struct cpuinfo_x86 *c, unsigned int feature) /* Take the capabilities and the BUG bits into account */ #define MAX_FEATURE_BITS ((NCAPINTS + NBUGINTS) * sizeof(u32) * 8) +/* + * Return the feature "name" if available, otherwise return + * the X86_FEATURE_* numerals to make it easier to identify + * the feature. + */ +static const char *x86_feature_name(unsigned int feature, char *buf) +{ + if (x86_cap_flags[feature]) + return x86_cap_flags[feature]; + + snprintf(buf, 16, "%d*32+%2d", feature / 32, feature % 32); + + return buf; +} + static void do_clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature) { DECLARE_BITMAP(disable, MAX_FEATURE_BITS); @@ -123,8 +138,12 @@ static void do_clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature) if (WARN_ON(feature >= MAX_FEATURE_BITS)) return; - if (boot_cpu_has(feature)) - WARN_ON(alternatives_patched); + if (boot_cpu_has(feature) && alternatives_patched) { + char feature_buf[16]; + + pr_err("x86/cpu: CPU feature %s cleared after alternatives patched\n", + x86_feature_name(feature, feature_buf)); + } clear_feature(c, feature); @@ -157,21 +176,6 @@ void setup_clear_cpu_cap(unsigned int feature) do_clear_cpu_cap(NULL, feature); } -/* - * Return the feature "name" if available, otherwise return - * the X86_FEATURE_* numerals to make it easier to identify - * the feature. - */ -static const char *x86_feature_name(unsigned int feature, char *buf) -{ - if (x86_cap_flags[feature]) - return x86_cap_flags[feature]; - - snprintf(buf, 16, "%d*32+%2d", feature / 32, feature % 32); - - return buf; -} - void check_cpufeature_deps(struct cpuinfo_x86 *c) { char feature_buf[16], depends_buf[16]; base-commit: f5098b6bae761e346ebcd9da7f95622c04733cff -- This is an AI-generated patch subject to moderation. Reply with '#syz upstream' to Sign-off the patch as a human author and send it to the upstream kernel mailing lists. Reply with '#syz reject' to reject it ('#syz unreject' to undo). See https://goo.gle/syzbot-ai-patches for information about AI-generated patches. You can comment on the patch as usual, syzbot will try to address the comments and send a new version of the patch if necessary. syzbot engineers can be reached at syzkaller@googlegroups.com.