There is no panic() text for this bug - that is the point.

All five crashes observed during verification (00:52, 00:55, 01:05,
01:06, 01:14 / 01:16 decisive run) show:
  * zero bytes on the serial console between the trigger and the boot
    loader reappearing (or SMP wedge messages: "smp_invltlb 1: WARNING
    blocked N sec" - see boot_v5_crash_serial.log / boot_final_crash_serial.log),
  * zero "panic" lines in /var/log/messages across the whole session,
  * no crash dump ("No core dumps found." on next boot, /var/crash empty),
  * QEMU monitor `info registers` right after the ss=0xdead crash shows
    CPU#0 in REAL MODE at the BIOS (CS=f000, EIP=0xea6c, CR0=0x10,
    IDT=0000:03ff) - i.e. the CPU was RESET:
    monitor_v1_reset.txt / monitor_final_reset.txt.

That signature is a triple-fault-class failure: the broken frame
reconstruction makes the kernel attempt an iretq with garbage
tf_cs/tf_rflags/tf_rsp/tf_ss (read from PCB padxx[] padding / stale
stack above the popped user frame), which re-faults below any handler
that could reach panic().

For ss=0x4 the observed manifestation is an SMP livelock instead: the
faulting CPU spins (interrupts off) in the fault cascade while the other
CPUs block forever in smp_invltlb waiting for it (boot_v5_crash_serial.log).