From nobody Mon Sep 28 16:21:58 2026 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 418D13A16B9 for ; Wed, 19 Aug 2026 22:27:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787178442; cv=none; b=jpvJGngzOQkd6FUMxsPQDfpcXaSolbH9KxnLn9B/cXU/O/jk2W6Thx1QOZAKIr0qs6Rp5HIlaCM1p6b9NwlC1rBMXaXS78XE92t11kmjGw9Hgh4Mogeio2BvNAz6U7QT/1t411PI1Dd2fqZ6J0Y79kq1yXE7p4ch5fbfNMsvqWo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787178442; c=relaxed/simple; bh=WGm3p5oM3zo05UQVhikGUeWmOuT3VK6db4qPSyq1cYo=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=tAeI9s+Ng5GpB9AJSqRHug1Xwi/XYg8GVX9cichAiO/R5uHiDSdrYqXg+aL8PaQ/AywZdxgLnTuuqndirWMxLPQvu92AvEADhbJiUu9TuT4ZknUEW77Clls650fG6xqxl5F/Lw9UTUxn1rNAGO24fcEpWmOur6pSYKaLN7EVYEc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=W58TD7NG; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="W58TD7NG" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-47f703a9d05so1018755f8f.0 for ; Wed, 19 Aug 2026 15:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787178439; x=1787783239; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=7ULPVsNiJGeOiMzRxtFMqgWR/S094ar6IrHsMXumteU=; b=W58TD7NGvkJGuJaAwixmRDAhJASHVfPE2oEJpIWnky+ktmNro/067QCl/8+xIENNOw r1hH68GD6RRI1GOWwJMJynC6ImeiWEuMvXPtjVQJw/Y4N1okVY4pobIQbkccEWk+c6VH zBh1qj3ICgHoZ7xpKRLJt4XlzVLxNHQlLu59H9M6gmVWu+0eAPnjEWbTtLMKX8ZQEpCX X2REAgSDJAMPrjh3qa1N02veFAWszp/S6ea3NaG/ebZFIH1FYzCQFO6Q31BqucvN9oD6 52iTbtaGjH59ZxRl1fDqjnZcFFUcX8Qz1vVQjLB+yHaUFMmK+TeUByOCgDhEuCdVrBqk s6rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787178439; x=1787783239; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=7ULPVsNiJGeOiMzRxtFMqgWR/S094ar6IrHsMXumteU=; b=CM83SzC0GbG2D2ppQb3DrEWulk8yRdNQ45ckmMjvUgG4mEDPqNdoLKhFwaCotpC+FE xZMn0tIVi6HaWBz0ssEokLMmkECfiwkbzaRzpw+w/SFZ7WoYw4cZFNLpZhdfCgWrx2mS HDkrGlr00tLd2bk+BGyVATaQ7SRDan2J+6PQhVaLninAjnuKWb3jaUXQoEepYlafY/kr 9rfVXesyW5TH05dEoKYE9h1953pLwY7G2kHFIcnCk2WAHyW+1l7NFOWipTWuCY8W7ieZ 0AFQjiOuH/6B62rnKKaGvPp83FRTuz+5PEwqa31Wd3xkSqBsaeDSj3A9Pz7JnCxuyHva +2yw== X-Forwarded-Encrypted: i=1; AHgh+RrFXigk65/tacQl7JD96kb88ijzX5WSLmsZyZe/8q/liSjn6UOVHtc/xUh4VYV7/im6BaTBPV6uPGuBlJA=@vger.kernel.org X-Gm-Message-State: AFuF++mhbMpJdPYfVMPUZc8kUkdqKF8pnHPxue8+MyDos3yGrDbx5ZwR yXjh8NvrrHF5a20fANjqhdN8mVp0zgRs7XsHcZMYc4PrMZC+BdxHvr3YzbJWjmFN X-Gm-Gg: AR+sD13Wcfmd/75UfkYw1JSFhN2YZtAYcUi1WHz2sA6KlChajjG31ycN4YQAkD9mbU2 jYB5SzcA8BOTDX30ApedWZsgkjq7hXk2X5x3uXsg8oo3fI427aFk8EAfBLcp+Wxt46ej2AnnQZJ mMsLZH81J/ppNLt6lMc6P2kjRNPaNnbR2DNq9ru/JeHQxnq6V0wYcyD5MZHR23+TWcZHwiw6ev/ LwO5hn9Drth+lw2EHRtJrgvhDGBuA5XTbn3Zw2MrmfBCXzXvKxPDyYnU8ZGnvjrnVzTEFFaPhNL ln4xnSnjpeV6kbgTK4Qhw05kCwTgk5/v6eMwyOAuGK/THDnHK6b0vYFbU+RnxShhSDgWYIpGuX2 QhWrmXoiuMjNJMSEX9lzPyT2erFdQtTfVDl5PjsNqWbQTUa6LqYJdI65nsZpNqkJqBOViLk5tGK FHFxfBx4bv3GDM3innifTSuWv5ZCKZf00h4YEucK+0GGjDU1WNrSw4IOU0STfW9eUX3IS8siRbH YQw42HPx7g+C5j5aHLA+v1bYgYolaClGXtxXK3otq50V5ZILo1eOCF4z89xuQp0EjTUkTqN8QqP um3Hslb8IPD5XnqdMVd9WNeMZ2zGxOc+3q+jMOQaw/AKDcTNFG+dxdD8dN2Tp+avS302ejwqTDP 8Gg== X-Received: by 2002:a05:6000:2c10:b0:47f:cb39:10c4 with SMTP id ffacd0b85a97d-482b1fd9f1emr13180340f8f.12.1787178439256; Wed, 19 Aug 2026 15:27:19 -0700 (PDT) Received: from localhost.localdomain (dynamic-2a02-3100-ae9e-1d01-58d3-443d-4fa6-01cd.310.pool.telefonica.de. [2a02:3100:ae9e:1d01:58d3:443d:4fa6:1cd]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-482b145153fsm8636030f8f.12.2026.08.19.15.27.18 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 19 Aug 2026 15:27:18 -0700 (PDT) From: Karl Mehltretter To: Catalin Marinas , Will Deacon Cc: Karl Mehltretter , Mark Rutland , Arnd Bergmann , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH v2] arm64: compat: Fix decrementing LDM/STM alignment emulation Date: Thu, 20 Aug 2026 00:27:12 +0200 Message-Id: <20260819222712.81855-1-kmehltretter@gmail.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The compat alignment emulator inherited unsigned long data addresses from the 32-bit ARM implementation. In do_alignment_ldmstm(), nr_regs is an unsigned int holding the transfer size. The function uses the same address addition for both transfer directions, negating nr_regs first for a decrementing LDM or STM. The 32-bit negation wraps before the addition, so the handler adds nearly 4 GiB instead of subtracting the transfer size. The resulting address lies outside the compat task's address space, so decrementing LDM/STM emulation fails, while incrementing forms work. For example, a backwards-moving copy routine using decrementing LDM/STM can take an alignment fault when called with unaligned pointers. The compat handler should emulate the transfer, but this bug instead causes SIGBUS. The offset negated in do_alignment_finish_ldst() is offset_union.un, which is already unsigned long and does not have this width mismatch. Make nr_regs unsigned long so its negation and the address arithmetic use the same width. Fixes: 3fc24ef32d3b ("arm64: compat: Implement misalignment fixups for mult= iword loads") Cc: stable@vger.kernel.org Suggested-by: Arnd Bergmann Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter --- Changes in v2: - Narrow the fix to nr_regs, leaving the address types unchanged (Arnd). - Leave 32-bit address-space wraparound out of scope. - Add Cc: stable@vger.kernel.org now that the fix is narrowly scoped. v1: https://lore.kernel.org/r/20260817000231.21311-1-kmehltretter@gmail.com Tested: An AArch32 reproducer was run under QEMU and on a Raspberry Pi 400 (Cortex-A72). An unaligned decrementing LDM gets SIGBUS with the baseline kernel and passes with v2 in both environments. arch/arm64/kernel/compat_alignment.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/compat_alignment.c b/arch/arm64/kernel/compa= t_alignment.c index b68e1d3..9b58d0a 100644 --- a/arch/arm64/kernel/compat_alignment.c +++ b/arch/arm64/kernel/compat_alignment.c @@ -114,8 +114,8 @@ do_alignment_ldrdstrd(unsigned long addr, u32 instr, st= ruct pt_regs *regs) static int do_alignment_ldmstm(unsigned long addr, u32 instr, struct pt_regs *regs) { - unsigned int rd, rn, nr_regs, regbits; - unsigned long eaddr, newaddr; + unsigned int rd, rn, regbits; + unsigned long eaddr, newaddr, nr_regs; unsigned int val; =20 /* count the number of registers in the mask to be transferred */ --=20 2.39.5 (Apple Git-154)