From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a8-smtp.messagingengine.com (fhigh-a8-smtp.messagingengine.com [103.168.172.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0AB143ACEFE for ; Mon, 17 Aug 2026 09:16:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.159 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786958173; cv=none; b=BP3aKwMamm1ikKThov36Mkl4jfaZPQDDt2CDBTUmvCflaOdVOLfGhIBYMn+Blju6aro6tiOSMPVjdJyrP9SqM1cwsgD+38SW6GEttsJdrevYVFR7OJql8Z0eI120j+o5IufsLcL3GWmCJcXV0bk/tEhvsw+JriQZ5MqrngZLYIM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786958173; c=relaxed/simple; bh=f65e6/bl7V2DPdLXzwP5uoZluMj/s1pN0nJ294JVYmA=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=XokCDJSCojTlKI9YT40QQKvj2/lHJB6mdAhH9SG9SSu7EceIHZVlVc1WcFgdYMFppGGnqBOH89ttPpgrOjbhpN/SzG1jBj+iQYIBvBOzB8qmyxAHV9qtI5+eW/CaYGpk5oLIYvQdVV8RsZUgRj0i063e0rJTUKn19suqJDA4Gf4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=M5XW31s/; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=AUrY68Iv; arc=none smtp.client-ip=103.168.172.159 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="M5XW31s/"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="AUrY68Iv" Received: from ams-compute-02.internal (ams-compute-02.internal [10.64.2.62]) by mailfhigh.phl.internal (Postfix) with ESMTP id C73B11400037; Mon, 17 Aug 2026 05:15:59 -0400 (EDT) Received: from ams-imap-03 ([10.64.2.23]) by ams-compute-02.internal (MEProxy); Mon, 17 Aug 2026 05:16:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1786958159; x=1787044559; bh=CtS9wSJO7yQxTeHMAqbEeeg30dK8tgff88uUJOqCVPk=; b= M5XW31s/udPv2pZep1A7RvH6dRxtxYIJkizEH9NHHV2iXiPI3Kugjb843ROAY05f JHHg0PUg3Nc9GZ0OOacvE47Ihsq9wYtMEpENtsWsKFA0K4EdewMOHOqumtsBdkN/ d+QFkSDi0KNQ5YDwJdZu5fJ20zM2zzK6GKqhP+ZdAFDOUmsg5+unQY2wN7Sxvw+Y 1R9RJ0jT9L9eM+cgDkFKm0K/0I2f9jI6cVUezeu/4VDP82hUoa5XpPosPMTWdsed ugyrVfXXWV8hTqRXBGtpcjJ2s7F5jJt5FI2hHkgiYG2cJTV/NVunP4HjmBI67ht6 bimh9f7ad/M1touSMnMKwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1786958159; x= 1787044559; bh=CtS9wSJO7yQxTeHMAqbEeeg30dK8tgff88uUJOqCVPk=; b=A UrY68IvOqOwZH3LMVdmaRTBhBX/+fvIFas5qgzW+p9IstKDMkeUA9lrjFIYAwJto IRUtP1DX8772QaGMTzsg1syumuxzFhZFbGRdLCRcthSteZynfnpixw2uUKrqbE/+ b3kRMnrHenfx//yr5PTEMYphhiZW6C82BbeAt2pZx0trBQNKiGJ7OL3+6mIwAgZY MYR0Ohaz9c4blY+iZAf+IWdblmDexaAP0SpEp2tA1fcd0VDkGR4C/D3PncUCH/2D OrukiWxFPercz1GMAIxU6UsD3gmGxvS653HonqqJ9aujBYWpubj60iP0xV2PxKN2 uh4GwHtT9R9SEG+xSCByw== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTEzp/LQEyITID0FxiIgeeeGn/7LhpnhWO/TT+0Xiqu2JHkRt1Oi8GQ32eBY6RLl3I RcuCYXzLT0qWSBZ6RtUHfBIt6Jjtyb5EVr4lvcg8ZHg9eYfkdCEJGge7iJwmUGbtHJt7J7 MR6O9EitekEWgMZPMkay3Ue8Pa+QeMu3Qed+am+jbogw0cSnjby1BBAQiZ5ZZ15FluJXv2 rmXnArupFuLb8Dn13N3K8OxKkTcKRo+DW43Hw+WTNsnRXqUCH5D/f+jODbY4UsfGNmNMU0 9G2XoexJjkHvVDj1/YOAzx2+16QpiEW4i0rK96q4+b06lTQSbliXtQ/lHW+fR9JwX5MXj4 JUauh9SS/CISKlVCOakMK23t6ZAbOJ6U54c+vndQf18C8F1p0p4XX+C40z4STNAQuz95kc KQMVk8oxoeBirHyNqSxqbjUNq0OaoC8/X8A2HndhabbjlvQH66O5wBDoAQr7XEaGdnrcwE TvpfNgVLt/b4coqpjc/9FyzkU+3yfFG05L97bu1qoK/b/JQELMpvggbfT/33mSBAkXsJbJ udwUeH6PEBUaEVpBpswczs6Ky4sVuPHoNSEgaJwMz3UutHPNIrUUojm6BK+pRhCnQGfHNJ pw1a0MDQcVdxyZV7+mTf4RCMTEc25K9dxE5s+6kAuLO6rFNyKm9LR2H3PYxw X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.ams.internal (Postfix, from userid 501) id 9517832A006E; Mon, 17 Aug 2026 05:15:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: Aqm_jcT6PvEF Date: Mon, 17 Aug 2026 11:15:33 +0200 From: "Arnd Bergmann" To: "Karl Mehltretter" , "Catalin Marinas" , "Will Deacon" Cc: "Mark Rutland" , "Ard Biesheuvel" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Message-Id: In-Reply-To: <20260817000231.21311-1-kmehltretter@gmail.com> References: <20260817000231.21311-1-kmehltretter@gmail.com> Subject: Re: [PATCH] arm64: compat: Keep alignment address arithmetic 32-bit Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, Aug 17, 2026, at 02:02, Karl Mehltretter wrote: > The compat alignment emulator inherited unsigned long data addresses > from the 32-bit ARM implementation. On arm64, negating the unsigned int > transfer size wraps it at 32 bits before it is added to a 64-bit > address. A decrementing LDM or STM therefore adds nearly 4 GiB instead > of subtracting its transfer size. The resulting address lies outside > the compat task's address space, so the access fails and the process > gets a spurious SIGBUS instead of the fixup. > > Using 64-bit addresses also prevents transfer and writeback arithmetic > from wrapping at the AArch32 address-space boundary. Hi Karl, Nice find! How did you come across this? Your patch looks correct to me, but it took me a bit to understand it, as I found the use of compat_ptr() and changing the addressing to 32-bit a little confusing at first. > unsigned int rd, rn, nr_regs, regbits; > - unsigned long eaddr, newaddr; > + u32 eaddr, newaddr; > unsigned int val; As I understand it, the underlying problem here is the 32-bit overflow of nr_regs. Wouldn't it be sufficient to just turn nr_regs into an 'unsigned long' or 'size_t' in both instances? > - if (get_user(val, (u32 __user *)eaddr)) > + if (get_user(val, > + (u32 __user *)compat_ptr(eaddr))) The individual compat_ptr() in each access looks like it would have been sufficient as well, by avoiding the effect of the overflow, and it also makes the address wrap back to zero at the end of the address space. What's a bit confusing here is that accessing an unaligned set of words at the end of the address space will still read a couple of bytes beyond the end of the 32-bit space. Again, none of this is wrong, just wondering whether a simpler change would make this easier to understand and keep the code closer to the original arm32 version. Arnd