UPDATE — New crash with spec_rstack_overflow=off: crash moved to retbleed_return_thunk
Following up on the proposed validation: instead of recompiling without CONFIG_MITIGATION_SRSO, I booted with `spec_rstack_overflow=off` (plus `processor.max_cstate=1` and `nmi_watchdog=1`). Confirmed active via dmesg and /proc/cmdline. Result: the system crashed again after ~26h uptime (2026-07-15 13:21 local), but this time the faulting RIP moved from srso_safe_ret to retbleed_return_thunk — same exact pattern (CPU 0, idle, timer interrupt): [95875.064234] BUG: unable to handle page fault for address: 0000573261ee7000 [95875.064242] #PF: supervisor instruction fetch in kernel mode [95875.064244] #PF: error_code(0x0010) - not-present page [95875.064246] PGD 0 P4D 0 [95875.064250] Oops: Oops: 0010 [#1] SMP NOPTI [95875.064253] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 7.0.0-27-generic #27-Ubuntu PREEMPT(lazy) [95875.064257] Hardware name: AZW SER/SER, BIOS SER_V1.14_P3C6M43_B_Link 03/24/2022 [95875.064259] RIP: 0010:retbleed_return_thunk+0x0/0x10 Call Trace: <IRQ> ? tick_nohz_handler ? update_process_times ? __hrtimer_run_queues ? hrtimer_interrupt ? __sysvec_apic_timer_interrupt ? sysvec_apic_timer_interrupt </IRQ> <TASK> ? asm_sysvec_apic_timer_interrupt ? cpuidle_enter_state+0xca/0x700 ? cpuidle_enter ? cpuidle_idle_call ? do_idle </TASK> Analysis: 1. All crashes (srso_safe_ret, kick_ilb, and now retbleed_return_thunk) share the same signature: CPU 0, swapper/0 in cpuidle, APIC timer interrupt, faulting inside or right after a return thunk. 2. Disabling SRSO did not fix it — the fault simply moved to the next active return thunk (retbleed_return_thunk, since RETBleed mitigation remained enabled with its untrained return thunk on this Zen2 CPU). 3. Note the faulting address 0000573261ee7000 is a userspace-looking address being fetched for execution in kernel mode, and CR2 changes between crashes. Combined with the fault moving between thunks, this suggests the return address itself is corrupted when the CPU wakes from idle to service the timer interrupt — the thunk is just where execution lands. 4. This increasingly looks like a deeper issue: either return-stack (RSB/RAS) state corruption on C-state exit on this Renoir platform (possibly BIOS/AGESA related — vendor abandoned this model, last BIOS is from 03/2022), or a kernel bug in the idle-exit path common to all thunks. Worth noting `amd_pstate: the _CPC object is not present in SBIOS` — the platform firmware is quite limited. 5. Interesting detail: processor.max_cstate=1 was active and the crash still occurred in cpuidle_enter_state. So C1/halt is enough to trigger it, or max_cstate=1 isn't preventing the problematic idle state on this platform (acpi_idle driver). Next step: I've now added `retbleed=off` as well (keeping spec_rstack_overflow=off, processor.max_cstate=1, nmi_watchdog=1). With both thunk-based mitigations off, returns should use plain `ret` — if the crash still happens, it will point at RAS corruption on idle-exit rather than any specific mitigation; if it stops, it confirms the thunk-patching interaction. New vmcore + dmesg available: /var/crash/202607151321/ (kernel 7.0.0-27-generic). Happy to attach or extract anything useful from it. -- 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
