Not reproducible on 7.2-rc5 with both mitigations enabled — 85h so far,
no bypass
Following up on the isolation work: the crash does not reproduce on mainline
v7.2-rc5 with retbleed and SRSO mitigations both active and **no bypass
parameters on the command line**.
## Test kernel
$ uname -rv
7.2.0-070200rc5-generic #202607262232 SMP PREEMPT_DYNAMIC Sun Jul 26
22:50:30 UTC 2026
Mainline build (`linux-image-unsigned-7.2.0-070200rc5-generic`,
version `7.2.0-070200rc5.202607262232`), installed 27 Jul.
Previous kernel, where the crash occurred, was `7.0.0-28-generic`
(7.0.0-28.28).
## Mitigations active — this is the point
retbleed: Mitigation: untrained return thunk; SMT enabled with STIBP
protection
spec_rstack_overflow: Mitigation: Safe RET
spectre_v2: Mitigation: Retpolines; IBPB: conditional; STIBP: always-on;
RSB filling
Kernel command line, unchanged from the distro default apart from
`nmi_watchdog=1`:
BOOT_IMAGE=/boot/vmlinuz-7.2.0-070200rc5-generic root=UUID=... ro quiet
splash
nmi_watchdog=1 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,...
No `retbleed=off`, no `spec_rstack_overflow=off`, no `processor.max_cstate`.
## Results
Two separate windows, not continuous uptime:
| Window | Start | End | Duration | Outcome |
|---|---|---|---|---|
| 1 | 27 Jul 18:44 | 29 Jul 08:43 | **38.0 h** | clean — ended by a power
outage, not a crash |
| 2 | 29 Jul 10:10 | ongoing | **85.0 h** | clean |
No call traces, no `invalid opcode`, no `BUG:`, and no vmcore in `/var/crash`
across either window.
For comparison, the failure intervals on 7.0.0-28 before any workaround:
| Window | Duration | Outcome |
|---|---|---|
| 8 Jul 13:53 → 10 Jul 10:59 | 45.1 h | crash |
| 10 Jul 11:00 → 12 Jul 01:23 | 38.4 h | crash |
| 12 Jul 12:45 → 14 Jul 09:53 | 45.1 h | crash/freeze |
| 14 Jul 10:43 → 15 Jul 13:20 | **26.6 h** | crash |
The current window is roughly 1.9x the worst historical interval and 3.2x the
shortest one.
I want to be careful about how much this proves, so for completeness: the two
windows where the machine was stable **with the workaround** (`retbleed=off`)
were 185.9 h and 103.1 h, both ended by voluntary reboots. So 85 h with the
mitigation enabled is well past every crash interval, but has not yet matched
the longest known-good runs.
## The idle path was exercised
Since the original reports pointed at cpuidle, the relevant counters on CPU 0
(where every crash occurred, always in `swapper/0` under a timer interrupt):
POLL ~709,000 entries
C1 ~37,700,000 entries
C2 ~9,400,000 entries
C3 ~55,100,000 entries
Deep C-states are unrestricted and heavily used, so the code path that used to
fail is being hit constantly.
## Hardware
AMD Ryzen 7 4800U with Radeon Graphics
family 23, model 96, stepping 1
microcode 0x860010d (updated early from 0x08600106)
Same machine, same microcode revision as during the failures.
## Recap of the isolation, for context
| # | Boot parameters | Result |
|---|---|---|
| 1 | `processor.max_cstate=1` | crashed — `srso_safe_ret+0x0/0x20`, invalid
opcode |
| 2 | `+ spec_rstack_overflow=off` | crashed — **moved** to
`retbleed_return_thunk+0x0/0x10` |
| 3 | `+ retbleed=off` | stable 185.9 h |
| 4 | `retbleed=off` only | stable 103.1 h, SRSO active, C-states unrestricted |
Test 2 was the informative one: disabling the SRSO mitigation did not remove the
crash, it only relocated it to the other return thunk. That is what pointed at
the return thunk mechanism rather than either mitigation specifically.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2160457
Title:
Kernel panic in srso_safe_ret / kick_ilb during sched_tick on AMD
Ryzen 7 4800U (Zen2)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160457/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
