Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2349738pxb; Mon, 20 Sep 2021 19:43:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmRIVpgLgQDqdcFLolEDH7yEd5HWLAYdTFiEtitxLMtcDatUO3AMWHoNcwNAUX2HMaXePZ X-Received: by 2002:a17:906:38ce:: with SMTP id r14mr31759877ejd.268.1632192235781; Mon, 20 Sep 2021 19:43:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632192235; cv=none; d=google.com; s=arc-20160816; b=qUg+Rc0twYq2xjDdgesD8Fv1+5lFuhE3WDpjCb//F66vTpelzwgG7f2LxGWxeqJZ9v Iwt3WtUPBi0Xzsnk7ju44nBvUNe0+3v+SGIJbe3j2cwpv7QpO95MWF4FTJwEZeKD7rBY 8FeiWEm2ePRQ1shApNWcSZ0lSc78TcrPWtN7liAARKwyXVfr6CZYPHu2A1rv7fmmy7Gr Ws73xXvSYIE9EKqu/8O1GlveRP9o5ziTVdiVQQvvqAxgtbQnjLD5KcbIk3A9YhutD3cw s+qoRcY0dYXWOWyvjemPIuRpZog30v0pl32r6VaXxhyaVkCJPvAiUKcRwhI0aVoh2bHh FhVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=I/nFR9LpQwyMHDEiWGzV4QWPnbl+u8hfWcVn4P8fPLE=; b=NnEMXoBG0Tt7sD1Vf4Y0AhUqM5kPMWIx8H723GEf58LqxkTlMYCRCoJR6nwN57gz3a wnwSWNBOWBHQLm2BMRoP3cdylpEdcTK/X/hgajvMLB3hwo7huxCYFGWqf2bGIbn/3juP Rtcw0uPfmHCjXgOD98eE1OMoMZPA6LhSt+e8nF79JPjues+q8a3K8fRkGKrTq7eoF8Du ixFlNfubiNs6TywE/7W6J/Qk62k69M1m+TwqKYlOSOjuS3Wx3PQ67SD/4onenxzSDCpk SoMb2r5L5e50JOnMRSJMbk6apLWphLB3hBHfFKnkP9a19zjY/j5/W61BZNMXLz7XiwWp 9Znw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=CfzLLcKt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r2si16577950eda.616.2021.09.20.19.43.31; Mon, 20 Sep 2021 19:43:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=CfzLLcKt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348133AbhITSVk (ORCPT + 99 others); Mon, 20 Sep 2021 14:21:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:35780 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376694AbhITSOP (ORCPT ); Mon, 20 Sep 2021 14:14:15 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 47A4763287; Mon, 20 Sep 2021 17:21:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632158477; bh=HzTPcJVTGan/rMt9PqtYiL85Ua2qbAclqKgVjq1StcI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CfzLLcKtEGfhV0rba+IX8sklQmX5LNuf0rLDqCbPKmvzwJuyyi0NZkuIA7T9+fMFx LxNfQj1k77nkZGZVGKlzXURbVbBoM990dH+iScbgUOYEpdyNDs8sMoK33S+GusxbW4 +UnG9ANeaDbB6CnwD+YppXZwLoPB6bMdkuN4IaXU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mikulas Patocka , Helge Deller Subject: [PATCH 5.4 174/260] parisc: fix crash with signals and alloca Date: Mon, 20 Sep 2021 18:43:12 +0200 Message-Id: <20210920163936.998061782@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210920163931.123590023@linuxfoundation.org> References: <20210920163931.123590023@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mikulas Patocka commit 030f653078316a9cc9ca6bd1b0234dcf858be35d upstream. I was debugging some crashes on parisc and I found out that there is a crash possibility if a function using alloca is interrupted by a signal. The reason for the crash is that the gcc alloca implementation leaves garbage in the upper 32 bits of the sp register. This normally doesn't matter (the upper bits are ignored because the PSW W-bit is clear), however the signal delivery routine in the kernel uses full 64 bits of sp and it fails with -EFAULT if the upper 32 bits are not zero. I created this program that demonstrates the problem: #include #include #include #include static __attribute__((noinline,noclone)) void aa(int *size) { void * volatile p = alloca(-*size); while (1) ; } static void handler(int sig) { write(1, "signal delivered\n", 17); _exit(0); } int main(void) { int size = -0x100; signal(SIGALRM, handler); alarm(1); aa(&size); } If you compile it with optimizations, it will crash. The "aa" function has this disassembly: 000106a0 : 106a0: 08 03 02 41 copy r3,r1 106a4: 08 1e 02 43 copy sp,r3 106a8: 6f c1 00 80 stw,ma r1,40(sp) 106ac: 37 dc 3f c1 ldo -20(sp),ret0 106b0: 0c 7c 12 90 stw ret0,8(r3) 106b4: 0f 40 10 9c ldw 0(r26),ret0 ; ret0 = 0x00000000FFFFFF00 106b8: 97 9c 00 7e subi 3f,ret0,ret0 ; ret0 = 0xFFFFFFFF0000013F 106bc: d7 80 1c 1a depwi 0,31,6,ret0 ; ret0 = 0xFFFFFFFF00000100 106c0: 0b 9e 0a 1e add,l sp,ret0,sp ; sp = 0xFFFFFFFFxxxxxxxx 106c4: e8 1f 1f f7 b,l,n 106c4 ,r0 This patch fixes the bug by truncating the "usp" variable to 32 bits. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman --- arch/parisc/kernel/signal.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/arch/parisc/kernel/signal.c +++ b/arch/parisc/kernel/signal.c @@ -238,6 +238,12 @@ setup_rt_frame(struct ksignal *ksig, sig #endif usp = (regs->gr[30] & ~(0x01UL)); +#ifdef CONFIG_64BIT + if (is_compat_task()) { + /* The gcc alloca implementation leaves garbage in the upper 32 bits of sp */ + usp = (compat_uint_t)usp; + } +#endif /*FIXME: frame_size parameter is unused, remove it. */ frame = get_sigframe(&ksig->ka, usp, sizeof(*frame));