Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1642157pxb; Fri, 20 Nov 2020 15:10:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJwCzO3wYVf0zGtzGC7afomul9EZI6mjzX/L6nEEM5Ps37V6Qq0xNwijU8UOOo8doiCw18pF X-Received: by 2002:a50:d701:: with SMTP id t1mr8320269edi.177.1605913820780; Fri, 20 Nov 2020 15:10:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605913820; cv=none; d=google.com; s=arc-20160816; b=im8uNG9RT7827lmg30U5gQVVPRxFBfr26w6KMBC3tkKU8wkFdmk7m0X+lN7pe0x71h MS9+daF0P0z8f5dJB+kdTkb1m9S4fKVMkE2aqY4W7N97l+qgzINmPQ3Q+KSBeL/mNf8S uj3DoajT55TgWJF9Sx4L4h5YCh8bdUqvGIO0BY6aymRPwO4EbKfU6H4QFZzbZc58kHN2 BNyVz5LtyqYsF2LCBRRwgur9aVp441i/hSud9Q6x4FBZ52XTFYB3ytQa7TPrH36npRDo FSrt0BPCYeVp9NgLRxUU/2Si9zvMWzYSDjX26/o3E0AhThly6aSg48Ko54MZ0Xe0DW7/ TgGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=WsItiRlY2ZsY1kLHaN9bW+mg6xUUzDuK1HmeXy3qoOM=; b=Brq55C9PzYyeaKG4fRQlAJKHAeUFN3p1TwGD9xVERzZqK5adhAoORTkdowUIW+G5oT LB+vyoX6aW/amwHUs2QqVrRsyMStllhLUb86fGVKgzTRKYIXIBxHH+VX6YLjU2ZC5Wez 6yrAlNu5jrhhUROyghTGEQOrmwpxr/O2CKvSFY1Tm9m52gIehUCLr46tJJRp24DTgVgV xOFFgX3pC8x540N+VVIScaTWUNm023jdrW24axPkknO2P6RWFZ02VTZq+P/rnWO7NtJv YkkaM1u5G7In2IDX1HaMP7LUVYCUu1LIcYmYnARWd/QyZIG5RSAiyowQsVeUrYbLGf3J //OA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=LULwD43R; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f7si2484181ejr.344.2020.11.20.15.09.58; Fri, 20 Nov 2020 15:10:20 -0800 (PST) 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=@google.com header.s=20161025 header.b=LULwD43R; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728161AbgKTXFH (ORCPT + 99 others); Fri, 20 Nov 2020 18:05:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727808AbgKTXFG (ORCPT ); Fri, 20 Nov 2020 18:05:06 -0500 Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D043C061A04 for ; Fri, 20 Nov 2020 15:05:06 -0800 (PST) Received: by mail-lj1-x242.google.com with SMTP id x9so11729736ljc.7 for ; Fri, 20 Nov 2020 15:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WsItiRlY2ZsY1kLHaN9bW+mg6xUUzDuK1HmeXy3qoOM=; b=LULwD43R9K6cuWxcFQ3hXHCXYhiJN+3GbIfFgwF3U+9D4uK3QRYGXhUNIUm/phAvgJ O1+dQBQPdrOTkni7W+oLdBOBc2AuCnoiRAW66303aXkiViycOcEDheImdEnAvuTIjXzp eLP5Sjq1o7lBd24nmSshBGwl7Y0U5t7ogW/mH3gP2dUJ1nM4usf4NwpQS82BRv6K9Yap EMrQjrG/eD9JrD4ypfMMHEas9+4anxoeUxQJeMNfyj46BkBpdcwCf7RtWmInwVepP2GK gV24+8jJQZTCASDuFsakteAbIMTSJCXGpatnCUddjQGQYa13xtA2KiDV3arQoVCzVSqZ QhLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WsItiRlY2ZsY1kLHaN9bW+mg6xUUzDuK1HmeXy3qoOM=; b=LlKz0OQCiiq9YMjLDwCj/xAAPRC3oMH6e4zpSUfcAGjSAH/BED6AiFdWeywpOuSsaw RXZ/HfEfZkhOe6Jc1qNnZAPP3hpOtz/PEiPldzA4/cK2ELoF07D7wT6ZGxrT9BQgf2W2 6gkkJ+1pq7oCnQWnsTIFakOsszB5lZ6greShBxak1pz6DinLIHGNTu1MYCRRyvHLBBc1 MrLozeqmJPRHoujHuRXiVdxosJt133/QLDitZCFbZU9pkQosIPZxv8AJ1ttBif+Barbn dz64tDN2eLeh7Bv+YZVrMx2rIiQM8tBahCXCZbAO+RKv/bhEgltM6JwUHEkmAD80B21l F9sA== X-Gm-Message-State: AOAM532Ctw9IuHYTsijKlvI3EPGa58gzhwbBe+H/sjEMYW+VN/84I/wE 2vnE6WkITUQtrZ/NMmdr9IvO9MiSF+imJRlwiiYPZw== X-Received: by 2002:a2e:8891:: with SMTP id k17mr8457473lji.326.1605913504291; Fri, 20 Nov 2020 15:05:04 -0800 (PST) MIME-Version: 1.0 References: <20201119190237.626-1-chang.seok.bae@intel.com> <20201119190237.626-4-chang.seok.bae@intel.com> In-Reply-To: <20201119190237.626-4-chang.seok.bae@intel.com> From: Jann Horn Date: Sat, 21 Nov 2020 00:04:38 +0100 Message-ID: Subject: Re: [PATCH v2 3/4] x86/signal: Prevent an alternate stack overflow before a signal delivery To: "Chang S. Bae" Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Andy Lutomirski , "the arch/x86 maintainers" , Len Brown , Dave Hansen , "H.J. Lu" , Dave Martin , Michael Ellerman , Tony Luck , "Ravi V. Shankar" , libc-alpha@sourceware.org, linux-arch , Linux API , kernel list , Hiroshi Shimamoto , Roland McGrath Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 19, 2020 at 8:40 PM Chang S. Bae wrote: > The kernel pushes data on the userspace stack when entering a signal. If > using a sigaltstack(), the kernel precisely knows the user stack size. > > When the kernel knows that the user stack is too small, avoid the overflow > and do an immediate SIGSEGV instead. > > This overflow is known to occur on systems with large XSAVE state. The > effort to increase the size typically used for altstacks reduces the > frequency of these overflows, but this approach is still useful for legacy > binaries. > > Here the kernel expects a bit conservative stack size (for 64-bit apps). > Legacy binaries used a too-small sigaltstack would be already overflowed > before this change, if they run on modern hardware. [...] > diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c > index ee6f1ceaa7a2..cee41d684dc2 100644 > --- a/arch/x86/kernel/signal.c > +++ b/arch/x86/kernel/signal.c > @@ -251,8 +251,13 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, size_t frame_size, > > /* This is the X/Open sanctioned signal stack switching. */ > if (ka->sa.sa_flags & SA_ONSTACK) { > - if (sas_ss_flags(sp) == 0) > + if (sas_ss_flags(sp) == 0) { > + /* If the altstack might overflow, die with SIGSEGV: */ > + if (!altstack_size_ok(current)) > + return (void __user *)-1L; > + > sp = current->sas_ss_sp + current->sas_ss_size; > + } A couple lines further down, we have this (since commit 14fc9fbc700d): /* * If we are on the alternate signal stack and would overflow it, don't. * Return an always-bogus address instead so we will die with SIGSEGV. */ if (onsigstack && !likely(on_sig_stack(sp))) return (void __user *)-1L; Is that not working? (It won't handle the case where the kernel fills up almost all of the alternate stack, and the userspace signal handler then overflows out of the alternate signal stack. But there isn't much the kernel can do about that...)