From: Pawan Gupta pawan.kumar.gupta@linux.intel.com
[ Upstream commit 98ff5c071d1cde9426b0bfa449c43d49ec58f1c4 ]
The retbleed select function leaves the mitigation to AUTO in some cases. Moreover, the update function can also set the mitigation to AUTO. This is inconsistent with other mitigations and requires explicit handling of AUTO at the end of update step.
Make sure a mitigation gets selected in the select step, and do not change it to AUTO in the update step. When no mitigation can be selected leave it to NONE, which is what AUTO was getting changed to in the end.
Suggested-by: Borislav Petkov bp@alien8.de Signed-off-by: Pawan Gupta pawan.kumar.gupta@linux.intel.com Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Acked-by: Borislav Petkov (AMD) bp@alien8.de Link: https://lore.kernel.org/20250611-eibrs-fix-v4-1-5ff86cac6c61@linux.intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Now let me analyze the impact and determine if this should be backported:
## Backport Status: YES
This commit should be backported to stable kernel trees for the following reasons:
### 1. **Fixes a Bug in Security Mitigation Logic** The commit fixes an inconsistency in the RETBleed mitigation selection logic where the mitigation could remain in the `AUTO` state after the selection and update steps. This is a bug in the security mitigation implementation that could potentially leave systems incorrectly configured.
### 2. **Small and Contained Fix** The changes are minimal and well-contained: - Removes the problematic `AUTO` state assignments in `retbleed_update_mitigation()` - Adds proper mitigation selection for Intel CPUs in `retbleed_select_mitigation()` - Removes unnecessary code paths (the `goto out` pattern) - Total changes are limited to ~30 lines of code in a single file
### 3. **Fixes Security Mitigation Consistency** The commit message explicitly states: "This is inconsistent with other mitigations and requires explicit handling of AUTO at the end of update step." This inconsistency in security mitigation handling is exactly the type of bug that should be fixed in stable kernels.
### 4. **Low Risk of Regression** The changes are straightforward: - Instead of leaving mitigation as `AUTO`, it now explicitly selects `NONE` when no mitigation is available - For Intel CPUs, it properly selects EIBRS/IBRS/NONE based on CPU features during the select phase - The logic flow is simplified by removing the `goto out` pattern
### 5. **Security-Critical Subsystem** RETBleed is a serious CPU vulnerability (CVE-2022-29900 and CVE-2022-29901) that allows arbitrary speculative code execution. Any bugs in its mitigation logic should be promptly fixed in stable kernels to ensure users are properly protected.
### 6. **Clear Intent for Stable** While not explicitly marked with a "Cc: stable" tag, this is clearly a bugfix for security mitigation code, which typically qualifies for stable backporting according to stable kernel rules.
The commit ensures that the RETBleed mitigation selection process works correctly and consistently, preventing situations where the mitigation might be left in an undefined `AUTO` state. This is particularly important for security-conscious environments that rely on proper CPU vulnerability mitigations.
arch/x86/kernel/cpu/bugs.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index ea7f94438254..1f4146b9101a 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1250,6 +1250,14 @@ static void __init retbleed_select_mitigation(void) retbleed_mitigation = RETBLEED_MITIGATION_IBPB; else retbleed_mitigation = RETBLEED_MITIGATION_NONE; + } else if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) { + /* Final mitigation depends on spectre-v2 selection */ + if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) + retbleed_mitigation = RETBLEED_MITIGATION_EIBRS; + else if (boot_cpu_has(X86_FEATURE_IBRS)) + retbleed_mitigation = RETBLEED_MITIGATION_IBRS; + else + retbleed_mitigation = RETBLEED_MITIGATION_NONE; } }
@@ -1258,9 +1266,6 @@ static void __init retbleed_update_mitigation(void) if (!boot_cpu_has_bug(X86_BUG_RETBLEED) || cpu_mitigations_off()) return;
- if (retbleed_mitigation == RETBLEED_MITIGATION_NONE) - goto out; - /* * retbleed=stuff is only allowed on Intel. If stuffing can't be used * then a different mitigation will be selected below. @@ -1271,7 +1276,7 @@ static void __init retbleed_update_mitigation(void) its_mitigation == ITS_MITIGATION_RETPOLINE_STUFF) { if (spectre_v2_enabled != SPECTRE_V2_RETPOLINE) { pr_err("WARNING: retbleed=stuff depends on spectre_v2=retpoline\n"); - retbleed_mitigation = RETBLEED_MITIGATION_AUTO; + retbleed_mitigation = RETBLEED_MITIGATION_NONE; } else { if (retbleed_mitigation != RETBLEED_MITIGATION_STUFF) pr_info("Retbleed mitigation updated to stuffing\n"); @@ -1297,15 +1302,11 @@ static void __init retbleed_update_mitigation(void) if (retbleed_mitigation != RETBLEED_MITIGATION_STUFF) pr_err(RETBLEED_INTEL_MSG); } - /* If nothing has set the mitigation yet, default to NONE. */ - if (retbleed_mitigation == RETBLEED_MITIGATION_AUTO) - retbleed_mitigation = RETBLEED_MITIGATION_NONE; } -out: + pr_info("%s\n", retbleed_strings[retbleed_mitigation]); }
- static void __init retbleed_apply_mitigation(void) { bool mitigate_smt = false;