Reproduced on 7.0.0-38-generic, which already includes "x86/bugs: Make
Safe-RET robust against interrupt injection"
My last comment (#15) reported 48 hours without a crash on 7.0.0-29.
That result did not hold up over a longer window. Below is a new crash
on the current kernel with the full splat, followed by what happened
in between.
== New crash: 7.0.0-38-generic, 2026-10-25 15:34 UTC ==
7.0.0-38.38 contains "x86/bugs: Make Safe-RET robust against interrupt
injection" (upstream stable patchset 2026-08-26, LP: #2165189,
CVE-2026-68480), confirmed in the package changelog. No workaround on
the command line:
quiet splash nmi_watchdog=1
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
retbleed: Mitigation: untrained return thunk; SMT
enabled with STIBP protection
spec_rstack_overflow: Mitigation: Safe RET
Uptime at the panic was 48h23m, with the machine idle. kdump captured
it and the system rebooted on its own. Full splat from the kdump
dmesg:
Oops: invalid opcode: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted
7.0.0-38-generic #38-Ubuntu PREEMPT(lazy)
Hardware name: AZW SER/SER, BIOS SER_V1.14_P3C6M43_B_Link 03/24/2022
RIP: 0010:srso_return_thunk+0x5/0x5f
Code: cc cc cc 48 b8 48 8d 64 24 08 c3 cc cc 0f ae e8 e8 f0 ff ff
ff 0f 0b 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 e8 db ff ff ff <0f>
0b 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84
RSP: 0018:ffffcf9100003ec0 EFLAGS: 00010046
RAX: ffff8d8c0ca7f700 RBX: ffff8d8eff233500 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffcf9100003f10 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d8c803ad000
R13: ffff8d8c1cf5b000 R14: ffff8d8c1cf5b000 R15: ffff8d8c1cf5b148
FS: 0000000000000000(0000) GS:ffff8d8f5f9fb000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005e14b264b268 CR3: 0000000304244000 CR4: 0000000000350ef0
Call Trace:
<IRQ>
sched_balance_update_blocked_averages+0x63/0xc0
sched_balance_softirq+0x46/0x80
handle_softirqs+0xe1/0x360
__irq_exit_rcu+0x100/0x120
? srso_return_thunk+0x5/0x5f
irq_exit_rcu+0xe/0x20
sysvec_apic_timer_interrupt+0x9f/0xd0
</IRQ>
<TASK>
? srso_return_thunk+0x5/0x5f
asm_sysvec_apic_timer_interrupt+0x1b/0x20
RIP: 0010:cpuidle_enter_state+0xca/0x700
Code: 00 e8 0a c8 dc fe e8 c5 ec ff ff 49 89 c5 0f 1f 44 00 00 31
ff e8 e6 b2 da fe 80 7d d0 00 0f 85 c6 01 00 00 fb 0f 1f 44 00 00 <45>
85 e4 0f 88 3e 02 00 00 4d 63 fc 49 83 ff 0a 0f 83 1d 05 00 00
RSP: 0018:ffffffff9ee03d90 EFLAGS: 00000246
RAX: 0000000000000000 RBX: ffff8d8c0098e000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffffff9ee03de0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
R13: 00009e6e6094eb85 R14: ffffffff9f16a500 R15: 0000000000000001
? srso_return_thunk+0x5/0x5f
? put_task_stack+0x92/0xd0
? srso_untrain_ret+0x2/0x2
cpuidle_enter+0x30/0x50
call_cpuidle+0x21/0x50
cpuidle_idle_call+0x16b/0x1f0
? srso_return_thunk+0x5/0x5f
do_idle+0x94/0xf0
cpu_startup_entry+0x29/0x30
rest_init+0xef/0xf0
start_kernel+0x4b4/0x4c0
x86_64_start_reservations+0x24/0x30
x86_64_start_kernel+0x134/0x140
common_startup_64+0x13e/0x141
</TASK>
Modules linked in: sp5100_tco xt_mark wireguard libcurve25519 veth
nf_conntrack_netlink xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE
bridge stp llc xfrm_user xfrm_algo xt_set ip_set nft_chain_nat nf_nat
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype nft_compat
x_tables nf_tables nfnetlink vxlan ip6_udp_tunnel udp_tunnel ccm
rfcomm snd_seq_dummy snd_hrtimer overlay uhid cmac algif_hash
algif_skcipher af_alg bnep binfmt_misc amdgpu nls_iso8859_1
snd_sof_amd_acp70 snd_sof_amd_acp63 snd_sof_amd_vangogh
snd_sof_amd_rembrandt snd_sof_amd_renoir snd_sof_amd_acp snd_sof_pci
snd_sof_xtensa_dsp snd_sof snd_sof_utils snd_pci_ps
snd_soc_acpi_amd_match snd_amd_sdw_acpi soundwire_amd
soundwire_generic_allocation snd_hda_codec_alc269 intel_rapl_msr
amd_atl r8153_ecm soundwire_bus intel_rapl_common
snd_hda_codec_realtek_lib cdc_ether snd_hda_scodec_component
snd_soc_sdca usbnet snd_hda_codec_generic snd_hda_codec_atihdmi
snd_hda_codec_hdmi snd_soc_core snd_hda_intel edac_mce_amd
snd_compress snd_hda_codec ac97_bus
snd_pcm_dmaengine mt7921e kvm_amd snd_hda_core snd_rpl_pci_acp6x
mt7921_common snd_acp_pci snd_intel_dspcfg snd_amd_acpi_mach amdxcp
ee1004 snd_intel_sdw_acpi mt792x_lib snd_acp_legacy_common
drm_panel_backlight_quirks kvm snd_hwdep mt76_connac_lib gpu_sched
snd_pci_acp6x snd_seq_midi mt76 drm_buddy irqbypass snd_seq_midi_event
snd_pcm btusb drm_ttm_helper btmtk rapl snd_rawmidi ttm snd_pci_acp5x
btrtl mac80211 snd_seq drm_exec btbcm drm_suballoc_helper btintel
r8152 mii snd_seq_device drm_display_helper snd_rn_pci_acp3x r8169
snd_acp_config bluetooth i2c_piix4 k10temp snd_timer snd_soc_acpi cec
snd_pci_acp3x cfg80211 i2c_smbus rc_core snd realtek i2c_algo_bit
libarc4 soundcore joydev mac_hid sch_fq_codel efi_pstore
hid_logitech_hidpp hid_logitech_dj hid_generic usbhid video wmi ccp
nvme nvme_core ahci nvme_keyring i2c_hid_acpi ghash_clmulni_intel
nvme_auth libahci hkdf i2c_hid hid uas usb_storage lp ppdev parport
msr dmi_sysfs autofs4 aesni_intel
Reading the Code line: the bytes right before the faulting address are
"e8 db ff ff ff" (the call to srso_safe_ret inside srso_return_thunk)
and the faulting instruction is "0f 0b" (ud2). So execution resumed at
the return address pushed by that call. srso_safe_ret is "lea
0x8(%rsp),%rsp; ret", which is meant to discard that address and
return to the thunk's caller, so this ud2 should be unreachable. My
reading, not a proof: the ret consumed a stack slot 8 bytes away from
the intended one.
== Earlier crash with the same shape: 7.0.0-31-generic, 2026-09-08 ==
Same idle path, same mitigations, no workaround. I analysed that
vmcore with crash at the time:
panic message: "BUG: kernel tried to execute NX-protected page -
exploit attempt? (uid: 0)"
#PF: supervisor instruction fetch, error_code(0x0011)
RIP: srso_safe_ret (arch/x86/lib/retpoline.S:248)
PID 0, Comm swapper/0, Not tainted, uptime 3d23h
[exception RIP: srso_safe_ret]
__note_gp_changes <- note_gp_changes <- rcu_core <- rcu_core_si
<- handle_softirqs <- irq_exit_rcu <- sysvec_apic_timer_interrupt
--- <IRQ stack> ---
[exception RIP: cpuidle_enter_state+202]
The return target was rcu_state (data, hence the NX fault). That same
value was in CR2, in R15 and in the stack word adjacent to the return
slot, while the legitimate return address (rcu_accelerate_cbs+41) was
in R14. That also looks like the ret in srso_safe_ret taking the wrong
stack slot.
Both crashes: CPU 0, swapper, timer interrupt arriving in
cpuidle_enter_state+0xca, softirq on irq exit, fault on the SRSO
return path. This matches Crash #1 in the original report
(srso_safe_ret+0x0 from cpuidle_enter_state+0xca via
sysvec_apic_timer_interrupt).
== Timeline since #15 ==
- 7.0.0-29 and 7.0.0-30: runs of up to 134h and 232h, but also unclean
endings. Only one of them left a vmcore (2026-09-03, 7.0.0-30): a
fault in alloc_fd+0x63 in process context, with the code in memory
identical to vmlinux and the fdtable intact. I could not attribute it
to this bug or rule it out, so I am not counting it.
- 7.0.0-31, SRSO Safe RET: the 2026-09-08 vmcore above.
- 7.0.0-31 with spec_rstack_overflow=off (SRSO "Vulnerable", retbleed
still mitigated): kdump captured two more panics, on 2026-09-14 and
2026-09-17. Those vmcores were removed by the daily apport cleanup of
/var/crash (it deletes directories older than 7 days) before I
extracted their traces, so I cannot say where they faulted. Dumps now
go to a directory outside /var/crash.
- 7.0.0-34, SRSO Safe RET, no workaround: 216h, ended by a clean
reboot into 7.0.0-38.
- 7.0.0-38: two hard hangs while idle (2026-10-04 and 2026-10-20) with
no panic and no automatic reboot, despite nmi_watchdog=1,
hardlockup_panic=1, softlockup_panic=1 and panic=60. kdump was
verified end to end with sysrq-c on 2026-10-04 (vmcore written,
automatic reboot). I cannot tell whether those hangs are the same bug.
Then today's panic.
== C-states ==
cpuidle driver is acpi_idle: C1 (FFH MWAIT 0x0), C2 (I/O port 0x414,
350 us) and C3 (I/O port 0x415, 400 us). Since 2026-10-20 C3 has been
disabled on all 16 CPUs through
/sys/devices/system/cpu/cpu*/cpuidle/state3/disable, as a test for the
idle hangs. Today's panic happened with C3 disabled (verified 16/16
after boot), so the CPU was coming out of C1 or C2. Avoiding the
deepest state does not avoid the bug.
== Platform, unchanged ==
AZW (Beelink) SER, Ryzen 7 4800U (family 23, model 96, stepping 1),
microcode 0x0860010d (amd64-microcode 3.20251202.1ubuntu2). BIOS
SER_V1.14_P3C6M43_B_Link (2022-03-24) is still the only BIOS the
vendor publishes for this model; I checked their download server again
this week.
== Available ==
vmcore (241 MB) and dmesg for today's crash. I can run crash commands
against it, or upload it wherever the kernel team prefers.
Since mainline 7.2-rc5 did not reproduce in 332 hours with both
mitigations enabled (#12, #14), is there a newer mainline build you
would like me to run, or a specific patch to test on top of 7.0.0-38?
--
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
