mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Stack error through asynchronous cancellation
@ 2022-11-21 20:54 Markus Wichmann
  2022-11-21 23:42 ` Rich Felker
  0 siblings, 1 reply; 2+ messages in thread
From: Markus Wichmann @ 2022-11-21 20:54 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-11-21 23:42 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-21 20:54 [musl] Stack error through asynchronous cancellation Markus Wichmann
2022-11-21 23:42 ` Rich Felker

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).