From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752285AbdGDXCq (ORCPT ); Tue, 4 Jul 2017 19:02:46 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:52621 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752169AbdGDXCp (ORCPT ); Tue, 4 Jul 2017 19:02:45 -0400 Message-ID: <1499209315.2707.29.camel@decadent.org.uk> Subject: Re: [PATCH] mm: larger stack guard gap, between vmas From: Ben Hutchings To: Michal Hocko , Willy Tarreau Cc: Linus Torvalds , Hugh Dickins , Oleg Nesterov , "Jason A. Donenfeld" , Rik van Riel , Larry Woodman , "Kirill A. Shutemov" , Tony Luck , "James E.J. Bottomley" , Helge Diller , James Hogan , Laura Abbott , Greg KH , "security@kernel.org" , linux-distros@vs.openwall.org, Qualys Security Advisory , LKML , Ximin Luo Date: Wed, 05 Jul 2017 00:01:55 +0100 In-Reply-To: <20170704113611.GA4732@decadent.org.uk> References: <20170619142358.GA32654@1wt.eu> <1498009101.2655.6.camel@decadent.org.uk> <20170621092419.GA22051@dhcp22.suse.cz> <1498042057.2655.8.camel@decadent.org.uk> <1499126133.2707.20.camel@decadent.org.uk> <20170704084122.GC14722@dhcp22.suse.cz> <20170704093538.GF14722@dhcp22.suse.cz> <20170704094728.GB22013@1wt.eu> <20170704104211.GG14722@dhcp22.suse.cz> <20170704113611.GA4732@decadent.org.uk> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-G8JTb+Qhk1iBvhPOaejZ" X-Mailer: Evolution 3.22.6-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-G8JTb+Qhk1iBvhPOaejZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-07-04 at 12:36 +0100, Ben Hutchings wrote: [...] > This *doesn't* fix the LibreOffice regression on i386. gdb shows me that the crash is at the last statement in this function: static void _expand_stack_to(address bottom) { =C2=A0 address sp; =C2=A0 size_t size; =C2=A0 volatile char *p; =C2=A0 // Adjust bottom to point to the largest address within the same pag= e, it =C2=A0 // gives us a one-page buffer if alloca() allocates slightly more me= mory. =C2=A0 bottom =3D (address)align_size_down((uintptr_t)bottom, os::Linux::pa= ge_size()); =C2=A0 bottom +=3D os::Linux::page_size() - 1; =C2=A0 // sp might be slightly above current stack pointer; if that's the c= ase, we =C2=A0 // will alloca() a little more space than necessary, which is OK. Do= n't use =C2=A0 // os::current_stack_pointer(), as its result can be slightly below = current =C2=A0 // stack pointer, causing us to not alloca enough to reach "bottom". =C2=A0 sp =3D (address)&sp; =C2=A0 if (sp > bottom) { =C2=A0=C2=A0=C2=A0=C2=A0size =3D sp - bottom; =C2=A0=C2=A0=C2=A0=C2=A0p =3D (volatile char *)alloca(size); =C2=A0=C2=A0=C2=A0=C2=A0assert(p !=3D NULL && p <=3D (volatile char *)botto= m, "alloca problem?"); =C2=A0=C2=A0=C2=A0=C2=A0p[0] =3D '\0'; =C2=A0 } } We have: bottom =3D 0xff803fff sp =3D 0xffffb178 The relevant mappings are: ff7fc000-ff7fd000 rwxp 00000000 00:00 0 fffdd000-ffffe000 rw-p 00000000 00:00 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0[stack] So instead of a useless guard page, we have a dangerous WX page underneath the stack! I suppose I should find out where and why that's being allocated. Ben. --=20 Ben Hutchings The world is coming to an end. Please log off. --=-G8JTb+Qhk1iBvhPOaejZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAllcHmMACgkQ57/I7JWG EQlBUQ//Vujj6pPwG2O/0vRyBXGgw8d6MxI3hO1mJNys1grrJ4xIlmOG4K89oGBJ i2egWqK0m1tKPpSLbdR7eDmwnKU3vHxzyf1Q3ou1RA2wv4p2XPrDa1TEF0H6qy7h avNMgLCQ7RjOqwyqKeErBrgXT6DfjRAO+SIz4KJom77xXyCn+GS3ru1sDVDVm8a8 v5c8GZmivAAfZ7h3dni8NC2Sk6L+NTQaHa9PfyxX+P65FHMS4wvi+F/up4fr1HRI C134C77IJVApo6bh3GfaBW3WK0SmJDkDwbnGKKf7YFIuyqRgWeuPkWpswhUwj7Ll x9i54yUpdy0wlamNp4K+jfnKfHn8Jrl2flvMD0y0xZKvWfuMv39tk4DU6P/m8Cfo X+nJJiyRqka7UWTgosaQmlrpHYafRSN7Yj6KROtBLP+JhofDVelZ4VnKltBegKHm ULDpUV8cqMGXmK8IgkNGMaL8TPuxzbFliZ9Of3wDeEUuJDeK15Z04vdQSQkfl4yp etqCcsijkKFaYvxf8UNmJFsyvHZ9FQnBD1T2oIFftjf0XM+EiX51j4Yi2/6hv4gP NsFNUd7YKjaTlK+s4jmbt91x/kYK6bzGSKHZ+OWdm8r8g8lLcEXq7XT+IEJ4bzhJ 6rLUZLqpBOu/QyPcXRRRBfa/ZPM+gjuBKFoxI51dTmUd2Di0ysY= =bhFO -----END PGP SIGNATURE----- --=-G8JTb+Qhk1iBvhPOaejZ--