[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221121205413.GC2497@voyager>
Date: Mon, 21 Nov 2022 21:54:13 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Stack error through asynchronous cancellation
Hi all,
I noticed that when a thread is cancelled while asynchronous
cancellation is in effect, then execution is redirected to __cp_cancel,
but __cp_cancel is a label only meant to undo the stack manipulation of
__syscall_cp, then jump to __cancel. This means, during asynchronous
cancellation, invalid values will be read from stack, and the stack
pointer may be set to a misaligned value before continuing to
__cp_cancel. For the most part, it will not matter, since __cancel will
not return if asynchronous cancellation is in effect, but there is still
something iffy about this whole behavior.
I wonder if we maybe need a new label __cp_cancel_async, that
transitions to __cancel from unknown legal processor state. On x86_64,
for example, it is possible (though unlikely) that the direction flag is
set, thus leading to undefined behavior when __cancel is invoked with
the flag set, even though the ABI says it is not supposed to be set on
entry to any function.
On architectures that do actually adjust the stack in __syscall_cp, the
changes to the stack pointer could also mean overwriting a thread
cancellation handler. And while pthread_cleanup_push() and ..._pop() are
not async-cancel-safe, can they not be invoked under deferred
cancellation and then have asynchronous cancellation be used between
them?
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
