Re: [PATCH 1/3] x86/shstk: ban ia32 sigreturn when shadow stack is enabled
From: Richard Patel
Date: Thu Oct 08 2026 - 17:55:35 EST
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.