linux-kernel - [RFC][possible bug] when should SS

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-next>] [day] [month] [year] [list]

Message-ID: <20200319021629.GC23230@ZenIV.linux.org.uk>
Date:   Thu, 19 Mar 2020 02:16:29 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Stas Sergeev <stsp@...t.ru>
Cc:     Ingo Molnar <mingo@...nel.org>, linux-api@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [RFC][possible bug] when should SS_AUTODISARM have effect?

	Consider the following scenario:  SIGPIPE has SA_ONSTACK
handler, SIGSEGV - non-SA_ONSTACK one.  SIGPIPE is delivered
and we fail halfway through setting a sigframe for it.
OK, we get SIGSEGV forced in, which gets handled not on altstack.
But what should happen if we fail *after* having saved the
altstack settings into the sigframe that got abandoned?

	AFAICS, we get them reset and the original setting
entirely lost.  Shouldn't that thing be applied only after
we have succeeded in building the frame?  In signal_delivered(),
perhaps...

	I realize that this is out of scope for POSIX, so it's
not a matter of standard compliance, but it looks like a bit
of a QoI issue...