From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D22001F454 for ; Mon, 4 Nov 2019 12:25:57 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=b957tlxfkNamjawK2Laf4NphJljtxMNsmDpIJDnOTck ZHGDwMhCvjvIEECogfuEG1wT6q4V+pQ70GeBJTbMJzG6crsTFLMLYoAjMZqMjcKL 0if9qJGFVrG6s48zVEpwA8Zpc+42AEIG7eVjD8dv+NF9T8Mozp0dlLVWKJx5PomA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; s=default; bh=AOG4frujEtMWla862n8SRs0ouq0=; b=R9QfPOdhZ3VGnGc9y 6cIWY5CE84b2Ls/0gA4+GD1wR0fvhEkKJ1N8cqKjXhOQLxklaj7iv3bBZuUpSF1G 9kS8uPCz7swJFUDMUTaJvcyhdn2LyqPEI4mG83+JIRImxZC8ZwsYpNjpayQnI1iB 0iHK6B06W3JOlF1RbjhpA/JQpI= Received: (qmail 89260 invoked by alias); 4 Nov 2019 12:25:55 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 89252 invoked by uid 89); 4 Nov 2019 12:25:55 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572870352; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Llkg7RIZDUpFOTY5TyVK2KSANqHRul14Uf89Z62wTsE=; b=HddZdziz6ge5oKfpZvo6ShLYysDzGxtFit2oc8XrwO4XMh4JnE/TdLRah6MWnPLPxT4PO1 EusVCFnZ+F5Zm4VUbCayWBgQkVrF7AJ6ljhIZhzQ/vY2aOAHHW+hrvjc17p6Z0we1Ehl0Y Q9ifI6i+EpH7gCdi/q7mXpz7EhadiMI= From: Florian Weimer To: Vinay Kumar Cc: libc-alpha@sourceware.org, carlos@redhat.com Subject: Re: Thread stack and heap caches - CVE-2019-1010024 References: Date: Mon, 04 Nov 2019 13:25:44 +0100 In-Reply-To: (Vinay Kumar's message of "Mon, 4 Nov 2019 16:39:58 +0530") Message-ID: <878sovvnef.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable * Vinay Kumar: > Regarding bug related to Thread stack and heap caches (CVE-2019-1010024). > https://sourceware.org/bugzilla/show_bug.cgi?id=3D22852 > >>> One way to harden is to use a tunable for a thread stack cache, and set= that to zero. > Below change in glibc allocatestack.c file gives the expected output > with test case. Verified on x86_64 target. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > --- a/nptl/allocatestack.c > +++ b/nptl/allocatestack.c > @@ -186,6 +186,7 @@ get_cached_stack (size_t *sizep, void **memp) > struct pthread *curr; > > curr =3D list_entry (entry, struct pthread, list); > + curr->stackblock_size =3D 0; > if (FREE_P (curr) && curr->stackblock_size >=3D size) > { > if (curr->stackblock_size =3D=3D size) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Does this really change the randomization? Won't the kernel map the new stack at a predictable address, too? Thanks, Florian