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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9965 invoked from network); 26 Mar 2023 21:16:40 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 26 Mar 2023 21:16:40 -0000 Received: (qmail 15670 invoked by uid 550); 26 Mar 2023 21:16:38 -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 15635 invoked from network); 26 Mar 2023 21:16:37 -0000 Date: Sun, 26 Mar 2023 17:16:24 -0400 From: Rich Felker To: ca0 Cc: "musl@lists.openwall.com" Message-ID: <20230326211623.GZ4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] socketcall syscall on x32 ABI producing incorrect results On Sun, Mar 26, 2023 at 09:12:41PM +0000, ca0 wrote: > I am running busybox with musl-1.2.3 on x32 linux with gcc-12.2.0. > > The syscall returns bad address in the case of the bind call. I have traced this down to the pointer being 0xf...... in 32bits being sign extended to 32bits in the syscall. > > Here is the code: > 0xf7f687ec 65 else r = __syscall(sys, a, b, c, d, e, f); > 0xf7f687e9 <__alt_socketcall+178>: 48 63 d0 movslq %eax,%rdx > > I can see the address being sign extended as intended by the movslq instruction. > > If I change the bind implementation to cast this address I do not see this issue, but other issues arise with the soecket call > > ie. in bind > int bind(int fd, const struct sockaddr *addr, socklen_t len) > { > long b = ((unsigned long)(addr) & 0xffffffff); > freturn socketcall(bind, fd, b, len, 0, 0, 0); > } > > Is this a known issue as x32 is marked as experimental. > > Sent with Proton Mail secure email. Thanks! I think this is fixed upstream already (not in a release) in commit 2404d9d643763e6eceafa9a1918925d80a84ad44. Let us know if you think that doesn't solve it. Rich