From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31445 invoked from network); 21 Nov 2022 20:54:29 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Nov 2022 20:54:29 -0000 Received: (qmail 17758 invoked by uid 550); 21 Nov 2022 20:54:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17723 invoked from network); 21 Nov 2022 20:54:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1669064053; bh=z/un50/N3ZnFzS0jWV9EYwY2Lp/pj2YqJOIqTApjajk=; h=X-UI-Sender-Class:Date:From:To:Subject; b=AQ6k45yUH+cOe+pldAZ1H6gxMkZcn9hXaOba8DFxEBq202YdzJMAnWMxyaxPr0l79 60oNE2jQSCesmzcmafx83c7FDsbnr658YAgwt+F5X9/ndedEMyQQ2/estjZa7k+zy1 zIVAjGSye4MHQjs/PZi3vANGlinpjW+BEJGqSFcbNCFxqm/qpSWdoFdUS8ZaPVCMmh uSjB2FwrVXq6bqyr3wQj6eYBRZmhfRDpoAowpkV9oLooyvdrdd51WUm3F23TBwROd5 tXDx7y1TgKRBj/V9jl102Jl7KzQnKV5Hxy7WSFUDRi8F5IzDVFwdEAg07a8XpVaSaK W9TRkgHoCH0tQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Mon, 21 Nov 2022 21:54:13 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20221121205413.GC2497@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:WZPRyn2kQzcTS4mYnsrYzii3UwdvTK4bDTxaZtWy0BlfnCR4NIC iEIb84lne47IIYSd4L8nJTA1NEIF2qete4WFOvl1QUQ2NgAzS1x6J2EZgrNeYJaxZyNrfRc 95dLWieueuA9i3rKiImO1hAle382lmEupdzKW2zgLNSVRRgyM4m/ovd/eV7L1WEqgDQRuTK UFkDkzNUFe4p4aBDwZPDw== UI-OutboundReport: notjunk:1;M01:P0:9o/zEQx2g6w=;oJNsvbICPRuKb2UnMqnbrkRqo6s oazYVvQ36WMnHG/b7MReLSk2XCFlZPJhDmQgy9DI8YUJprawT4Ez0VUdfa9HxNxVnoYbiw4Yj vWKSXPDwZdPU5Y8bjPstLlOPmzIgYuo/df0K5EmR9hGHIEwqKZnsWlfB0m+BYF65QEOHKxlKn MBDY8moeSlZUx0JkL2cdQnKbR1gX57KjMQ7f5ZoXXdNxiy7HkvCT0V19bdYQAlMhCXs6gALb7 EsJ7Vrplio7tM/HG0cmFtoAbq5aUQoICLwuQ7yKiB9ry/6pG/ZIVM/I8oe+2ANRfDtpbWUTwY aV7FRGzK0dR98Y4bTbnUFuIoLKMBo6Hv/6H2BZHKw/SzZ9pI4oP3MnyzVSMdWyf2oxFqNlRY1 2aqc3RHXlSqsqpnGi8YNwSsVUKjwA97zUbq34dp4wmMoWi5TgnK9NvtpWFSXw7KvFbIIOlLgl 4DKFAKXksppaH2mmTxkm9oOWXZ+Kmu4gzFr4B3cMMzylxkfKhrsw/6TC4ZnFnngw4AJpcSOZ4 iql6VkgYKRitXWxnAnTw52PAmGUDennCO8phhNERnW8i04neJp2kK6/XkUaukDe+Z/SKYhN8r AT27YKz/PKNxL5JyydN/TDXtrZc5d/BD1MxjdK3ghU4It2PjaHL2DqgTo49baMyE2IEFlBVn1 gCM1tOCB29ykWgegFjR2TBf+066y/9hSZItZNNjJFIxJ2ZdRU5xhopD7sj8nR24QRhWL1ptYp +Bl3DmO6ygZk6bE1TMGS4VUYxpT695XySFxqIu3bUVt2eZG0pV8IurDefh4m7APgbpQcaKq9m zNYaFlh1FRO7uaHJ38arkDcwpteYN1kdfcETIIXboy3V2KMNsUL5W6O5Zwcs3h3MxnBev742z 8j4M3nb/u5TybEcM/HBdekM/a7+EV5xwmNcnLLrjX528nchVV0z3ILJdImV3xfykZ9Rq89z0K QybXXw== Subject: [musl] 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