From: David Kaplan david.kaplan@amd.com
[ Upstream commit d1cc1baef67ac6c09b74629ca053bf3fb812f7dc ]
The LFENCE retpoline mitigation is not secure but the kernel prints inconsistent messages about this fact. The dmesg log says 'Mitigation: LFENCE', implying the system is mitigated. But sysfs reports 'Vulnerable: LFENCE' implying the system (correctly) is not mitigated.
Fix this by printing a consistent 'Vulnerable: LFENCE' string everywhere when this mitigation is selected.
Signed-off-by: David Kaplan david.kaplan@amd.com Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Link: https://lore.kernel.org/20250915134706.3201818-1-david.kaplan@amd.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my comprehensive analysis of this commit and its historical context, here is my determination:
## **Backport Status: YES**
## Extensive Analysis
### Historical Context and Bug Origins
The LFENCE reporting inconsistency was introduced in **February 2022** by commit **eafd987d4a82c** ("x86/speculation: Warn about Spectre v2 LFENCE mitigation"). That commit revealed that:
1. **Neither Intel nor AMD recommend LFENCE retpoline anymore** - it's faster than regular retpoline but weaker in certain scenarios (particularly SMT) 2. Intel's STORM research team discovered that AMD's LFENCE/JMP mitigation is insufficient due to a race condition 3. AMD confirmed the findings and recommended using alternative mitigations (generic retpoline or IBRS)
The 2022 commit added `return sprintf(buf, "Vulnerable: LFENCE\n");` to the sysfs reporting function but **forgot to update the `spectre_v2_strings[]` array**, which still said `"Mitigation: LFENCE"`. This created a **3-year inconsistency** (2022-2025).
### What This Commit Fixes
Looking at the code changes in arch/x86/kernel/cpu/bugs.c:
**Line 2037** (spectre_v2_strings array): ```c -[SPECTRE_V2_LFENCE] = "Mitigation: LFENCE", +[SPECTRE_V2_LFENCE] = "Vulnerable: LFENCE", ```
**Lines 3544-3546** (spectre_v2_show_state function): ```c -if (spectre_v2_enabled == SPECTRE_V2_LFENCE) - return sysfs_emit(buf, "Vulnerable: LFENCE\n"); - ```
The special case is removed because now `spectre_v2_strings[spectre_v2_enabled]` already returns the correct "Vulnerable: LFENCE" string at line 3571.
### Verification That This Is Purely a Reporting Fix
By examining the code at lines 1631, 2160, and 2418, I confirmed that `SPECTRE_V2_LFENCE` is used throughout the code for actual mitigation logic (setting CPU features, configuring RSB filling, etc.). **This commit changes ONLY the display strings** - it doesn't touch any mitigation behavior.
### Impact and User Confusion
**Before this fix:** - **dmesg log**: "Mitigation: LFENCE" (misleading - implies system is protected) - **sysfs** (`/sys/devices/system/cpu/vulnerabilities/spectre_v2`): "Vulnerable: LFENCE" (correct)
**After this fix:** - **Both locations**: "Vulnerable: LFENCE" (consistent and correct)
This inconsistency could: 1. Mislead system administrators about their security posture 2. Confuse security scanning tools (like spectre-meltdown-checker) that parse these strings 3. Cause incorrect security audits and compliance checks 4. Make users think they're protected when they're not
### Why This Should Be Backported
1. **Fixes Important Security Information Bug**: Users need accurate information about their vulnerability status to make informed security decisions
2. **Very Small and Low-Risk Change**: - Only 7 lines changed (1 string modified, 3 lines removed) - No behavioral changes to actual mitigations - Self-contained in a single file - No side effects
3. **Long-standing Bug**: The inconsistency has existed since the 2022 security advisory (commit eafd987d4a82c)
4. **Affects Stable Kernels**: Any stable kernel that includes the 2022 warning commit should also get this fix to ensure consistent reporting
5. **Minimal Risk of Regression**: Since it only changes display strings, there's virtually no risk of introducing new bugs or breaking existing functionality
6. **Follows Stable Kernel Rules**: - Important bugfix ✓ - Minimal risk ✓ - Small and self-contained ✓ - Fixes user-visible issue ✓
### Missing Tags
The commit lacks a `Fixes:` tag (should reference eafd987d4a82c) and has no `Cc: stable@vger.kernel.org` tag, but these are likely oversights given the clear nature of the fix.
### Conclusion
**YES, this commit should be backported** to all stable kernel trees that contain commit eafd987d4a82c (v5.16+). It fixes misleading security information that could confuse users and tools, with virtually zero risk of regression since it only affects display strings.
arch/x86/kernel/cpu/bugs.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index b633b026c117d..692293f0bc1bb 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -2050,7 +2050,7 @@ static void __init spectre_v2_user_apply_mitigation(void) static const char * const spectre_v2_strings[] = { [SPECTRE_V2_NONE] = "Vulnerable", [SPECTRE_V2_RETPOLINE] = "Mitigation: Retpolines", - [SPECTRE_V2_LFENCE] = "Mitigation: LFENCE", + [SPECTRE_V2_LFENCE] = "Vulnerable: LFENCE", [SPECTRE_V2_EIBRS] = "Mitigation: Enhanced / Automatic IBRS", [SPECTRE_V2_EIBRS_LFENCE] = "Mitigation: Enhanced / Automatic IBRS + LFENCE", [SPECTRE_V2_EIBRS_RETPOLINE] = "Mitigation: Enhanced / Automatic IBRS + Retpolines", @@ -3634,9 +3634,6 @@ static const char *spectre_bhi_state(void)
static ssize_t spectre_v2_show_state(char *buf) { - if (spectre_v2_enabled == SPECTRE_V2_LFENCE) - return sysfs_emit(buf, "Vulnerable: LFENCE\n"); - if (spectre_v2_enabled == SPECTRE_V2_EIBRS && unprivileged_ebpf_enabled()) return sysfs_emit(buf, "Vulnerable: eIBRS with unprivileged eBPF\n");