From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 0A94D3857737 for ; Wed, 3 May 2023 11:56:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0A94D3857737 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683114978; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NU+1CxVfTIEeJogv3hia11mPGWNNi95mKzwfploHiMU=; b=Iw35+vYzSouTWWwnB62WTiw8MHZXuV1BAo8MSB4V9u1Os9BC+Yk1MIUdYkN9bVW6VDi4uT JgX2Ut9wBnmG5tXOZBjhvx95+opoyQTa+GzzgY4hWdxeswZR0S7ERMy7q4a2QuaGvQNr5x LtqICB232VCESADeAtulF9bvt0gu3fw= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-168-PLUM_NcSNiiI4YL_EGLXzg-1; Wed, 03 May 2023 07:56:16 -0400 X-MC-Unique: PLUM_NcSNiiI4YL_EGLXzg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B33BF800B35; Wed, 3 May 2023 11:56:15 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3EA3A2026D16; Wed, 3 May 2023 11:56:15 +0000 (UTC) From: Florian Weimer To: Varun Kumar E via Gcc Cc: Varun Kumar E Subject: Re: Probe emission in fstack-clash-protection References: Date: Wed, 03 May 2023 13:56:13 +0200 In-Reply-To: (Varun Kumar E. via Gcc's message of "Wed, 3 May 2023 10:06:49 +0530") Message-ID: <87pm7h4oiq.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Varun Kumar E. via Gcc: > Hello, > > https://godbolt.org/z/P3M8s8jqh > The above case shows that gcc first decreases the stack pointer and then > probes. > > As mentioned by Jeff Law (reference > ) > under "More issues with -fstack-check". If an asynchronous signal is > received between the decrement of stack pointer and probing of the pages. > *"In that case, the stack pointer could be pointing beyond the guard into > the heap. The signal arrives and the kernel transfers control to the > registered signal handler. That signal handler is then running while its > stack is pointing into the heap. Thus, the attacker has clashed the stack > and heap, and there's a reasonable chance they can gain control over the > program" * > > So, Shouldn't we first probe and if successful only then update the stack > pointer? Or Maybe I have understood it incorrectly. Let me rephrase a bit. The caller has asserted that (%rsp) is valid upon entry to the function because that's where the return address is stored. That means that (%rsp - 4096) is still in the guard page, so the subsequent probe works. But the kernel fault handler will not write to that location because it has to protect the return address and the red zone, so the first location used is (%rsp - 4096 - 8 - 128) or thereabouts. Jeff, this looks like a real bug to me. It doesn't affect the main thread on GNU/Linux because the kernel uses more than one page for the guard area. However, glibc uses exactly one page. We could change that to two pages on x86-64 at least without ill effects, I believe. Or fix GCC's probing to account for the red zone. Thanks, Florian