From: David Kaplan david.kaplan@amd.com
[ Upstream commit 930f2361fe542a00de9ce6070b1b6edb976f1165 ]
On Intel CPUs, the default retbleed mitigation is IBRS/eIBRS but this requires that a similar spectre_v2 mitigation is applied. If the user selects a different spectre_v2 mitigation (like spectre_v2=retpoline) a warning is printed but sysfs will still report 'Mitigation: IBRS' or 'Mitigation: Enhanced IBRS'. This is incorrect because retbleed is not mitigated, and IBRS is not actually set.
Fix this by choosing RETBLEED_MITIGATION_NONE in this scenario so the kernel correctly reports the system as vulnerable to retbleed.
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, here is my assessment:
## **Backport Status: YES**
### Analysis
**The Bug:** On Intel CPUs, when a user selects `spectre_v2=retpoline` (or another non-IBRS/eIBRS mitigation), the kernel correctly prints a warning message: ``` "WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!\n" ```
However, it does NOT update the `retbleed_mitigation` variable to `RETBLEED_MITIGATION_NONE`. This causes sysfs to incorrectly report "Mitigation: IBRS" or "Mitigation: Enhanced IBRS" when the system is actually vulnerable to retbleed attacks.
**The Fix:** The fix is minimal and surgical - adding just one line at arch/x86/kernel/cpu/bugs.c:1465: ```c retbleed_mitigation = RETBLEED_MITIGATION_NONE; ```
This ensures that when the warning is printed, the mitigation status is correctly set to NONE, causing sysfs to report "Vulnerable" instead of falsely claiming mitigation.
**Why This Should Be Backported:**
1. **Important Security Information Bug**: Users rely on sysfs security reporting to understand their system's vulnerability status. Incorrect reporting can lead to false sense of security.
2. **Affects Real Users**: Anyone running Intel systems with custom `spectre_v2=retpoline` configuration is affected by this misreporting.
3. **Minimal Risk**: The change is a single line setting a variable to NONE. It only affects the reporting path in the default case, making regression risk extremely low.
4. **No Architectural Changes**: This is purely a status reporting fix with no changes to actual mitigation mechanisms.
5. **Small and Contained**: The change is confined to one function (`retbleed_update_mitigation()`) in one file.
6. **Already Being Backported**: Evidence shows this commit has already been backported to at least one stable tree (commit 8429c98317d24 is a backport with "Upstream commit 930f2361fe542").
7. **Applicable to 6.17**: The buggy code exists in linux-autosel-6.17 (introduced in commit e3b78a7ad5ea7), so this fix is directly applicable.
**Code Change Verification:** The diff shows the fix correctly: - Adds braces around the if block - Adds `retbleed_mitigation = RETBLEED_MITIGATION_NONE;` to ensure correct reporting - This aligns with the existing pattern at lines 1444-1445 where RETBLEED_MITIGATION_NONE is set when retbleed=stuff fails
This commit meets all stable kernel backport criteria: it fixes an important bug, has minimal risk, introduces no new features, and is confined to a single subsystem.
arch/x86/kernel/cpu/bugs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index e817bbae01591..b633b026c117d 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1463,8 +1463,10 @@ static void __init retbleed_update_mitigation(void) retbleed_mitigation = RETBLEED_MITIGATION_EIBRS; break; default: - if (retbleed_mitigation != RETBLEED_MITIGATION_STUFF) + if (retbleed_mitigation != RETBLEED_MITIGATION_STUFF) { pr_err(RETBLEED_INTEL_MSG); + retbleed_mitigation = RETBLEED_MITIGATION_NONE; + } } }