linux-kernel - Re: sigaltstack breaks swapcontext()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 9 Jan 2016 02:40:03 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: sigaltstack breaks swapcontext()

09.01.2016 02:24, Andy Lutomirski пишет:
> On Fri, Jan 8, 2016 at 5:49 AM, Stas Sergeev <stsp@...t.ru> wrote:
>> 06.01.2016 21:05, Andy Lutomirski пишет:
>>> On Wed, Jan 6, 2016 at 7:45 AM, Stas Sergeev <stsp@...t.ru> wrote:
>>>
>>>> Hello.
>>>>
>>>> swapcontext() can be used with signal handlers,
>>>> it swaps the signal masks together with the other
>>>> parts of the context.
>>>> Unfortunately, linux implements the sigaltstack()
>>>> in a way that makes it impossible to use with
>>>> swapcontext().
>>>> Per the man page, sigaltstack is allowed to return
>>>> EPERM if the process is altering its sigaltstack while
>>>> running on sigaltstack. This is likely needed to
>>>> consistently return oss->ss_flags, that indicates
>>>> whether the process is being on sigaltstack or not.
>>>> Unfortunately, linux takes that permission to return
>>>> EPERM too literally: it returns EPERM even if you
>>>> don't want to change to another sigaltstack, but
>>>> only want to disable sigaltstack with SS_DISABLE.
>>>> To my reading of a man page, this is not a desired
>>>> behaviour. Moreover, you can't use swapcontext()
>>>> without disabling sigaltstack first, or the stack will
>>>> be re-used and overwritten by a subsequent signal.
>>>>
>>> The EPERM thing is probably also to preserve the behavior that nested
>>> SA_ONSTACK signals are supposed to work.  (Of course, the kernel gets
>>> this a bit wrong because it forgets to check ss in addition to sp.
>>> That would be relatively straightforward to fix.)
>> I don't think it needs a fix: in 64bit mode SS doesn't matter, and
>> in 32bit mode the SS is properly restored in a sighandler, so no
>> one can run sigaltstack() with non-flat SS (unless the DOS code
>> itself does this, which it does not).
> It's not sigaltstack that I'm thinking about.  It's signal delivery.
> If you end up in DOS mode with SP coincidentally pointing to the
> sigaltstack (but with different SS so it's not really the
> sigaltstack), then the signal delivery will malfunction.
Ah, sounds like a real bug then!
Though if bitness differ (64bit mode and signal comes from
32bit code), there is probably no need to check anything and
just switch the stack.