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.