On Thu, Oct 08, 2026 at 08:59:57PM +0000, Edgecombe, Rick P wrote: > On Thu, 2026-10-08 at 20:16 +0000, Richard Patel wrote: > > When returning from a signal via x32 or x64 rt_sigreturn, the > > shadow-stack-restore token is validated, but ia32 (rt_)sigreturn > > do not call restore_signal_shadow_stack(). > > > > With IA32_EMULATION, 'int $0x80' allows ia32 sigreturn in 64-bit > > mode, which could defeat sigreturn protection. > > > > Refuse ia32 sigreturn by forcing a SIGSEGV instead. > > How can it defeat protection? If doesn't process the shadow stack sigframe at > all, leaving the SSP where ever it was originally. What am I missing?
The selftest demonstrates that 'int $0x80' rt_sigreturn from 64-bit mode jumps to an arbitrary %eip in the signal frame (zero-extended to %rip), \ whereas the 'syscall' variant raises SIGSEGV if %rip is corrupt. I don't think it matters that SSP is still at the old place. It would only break 'ret' after sigreturn, but the problem is that the sigreturn itself is a wild jump. "defeat protection" was badly worded, I just meant that the 'syscall' path has protections that the 'int $0x80' path doesn't have, so I thought it'd be worth fixing. I might be missing something, maybe SHSTK never intended to defend against a wild sigreturn? Either way, it's not a security thing.
