From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752509AbdGETdY (ORCPT ); Wed, 5 Jul 2017 15:33:24 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:59175 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751868AbdGETdW (ORCPT ); Wed, 5 Jul 2017 15:33:22 -0400 Message-ID: <1499283163.2707.52.camel@decadent.org.uk> Subject: Re: [PATCH] mm: larger stack guard gap, between vmas From: Ben Hutchings To: Andy Lutomirski , Linus Torvalds Cc: Michal Hocko , Willy Tarreau , 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" , Qualys Security Advisory , LKML , Ximin Luo Date: Wed, 05 Jul 2017 20:32:43 +0100 In-Reply-To: References: <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> <1499209315.2707.29.camel@decadent.org.uk> <1499257180.2707.34.camel@decadent.org.uk> <20170705142354.GB21220@dhcp22.suse.cz> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-sNzlin+/JdRut51wZnW7" X-Mailer: Evolution 3.22.6-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 82.70.136.246 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 --=-sNzlin+/JdRut51wZnW7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2017-07-05 at 10:23 -0700, Andy Lutomirski wrote: [...] > Looking at it that way, I think a new inherited-on-exec flag is nucking f= uts. >=20 > I'm starting to think that the right approach is to mostly revert all > this stuff (the execve fixes are fine).=C2=A0=C2=A0Then start over and th= ink > about it as hardening.=C2=A0=C2=A0I would suggest the following approach: >=20 > =C2=A0- The stack gap is one page, just like it's been for years. Given that in the following points you say that something sounding like a stack gap would be "64k or whatever", what does "the stack gap" mean in this first point? > =C2=A0- As a hardening feature, if the stack would expand within 64k or > whatever of a non-MAP_FIXED mapping, refuse to expand it.=C2=A0=C2=A0(Thi= s might > have to be a non-hinted mapping, not just a non-MAP_FIXED mapping.) > The idea being that, if you deliberately place a mapping under the > stack, you know what you're doing.=C2=A0=C2=A0If you're like LibreOffice = and do > something daft and are thus exploitable, you're on your own. > =C2=A0- As a hardening measure, don't let mmap without MAP_FIXED position > something within 64k or whatever of the bottom of the stack unless a > MAP_FIXED mapping is between them. Having tested patches along these lines, I think the above would avoid the reported regressions. Ben. > And that's all.=C2=A0=C2=A0It's not like a 64k gap actually fixes these b= ugs for > real -- it just makes them harder to exploit. >=20 > [1] The code that GCC generates for char buf[bug number] and alloca() > is flat-out wrong.=C2=A0=C2=A0Everyone who's ever thought about it all al= l knows > it and has known about it for years, but no one cared to fix it. --=20 Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. --=-sNzlin+/JdRut51wZnW7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAlldPtsACgkQ57/I7JWG EQn4CQ//bUA9lYAHKU/ZJpDDZ8LX3diw1PVoRs3559cxrSH6ilQVOvir3MQSoukW EaeKwd2noO3JP9yIiCoVhzDCt2e5HN1zYmlOEuEaAWdtTipJ46md/wWQNnKORjKx dM1BYoGZR311EKGNVwFZzT8SvfHZJtrSJembAOJB5CFEUYcWusIiqIE4+TlMpnio j/V7jyjBd/GxHhL+VbcoVJ51LVOvA6HqTJv98HLOA3eGFO3IJ+NXHDKhjUveQIHk mSqWzO6IhvXJ9rQ4yIX/6yRBboj5snnxogRRI7IycYdl9Pyv/rrGLLDfzQT7Qswl q/JizCkHswFF7WYTRvYcw1rOErPVy6Hwvlao4/QOvxJpaTSX5+Yd8snr4G4mUOTr zokEXi2JiZXN2D58eYCVoV2qdYmscTN5wz4Yao2owWG638GEeBl/IFZ0I9nZJCAQ YkwBfKQ/Q/1IzK6s9Fdlk3vKe4MuQ831tw2u+/bHbfvWEPB3rg1H/yLGdj+ULG+X 2q4TzfXIS8DrFJGLHPz32yCpDXtCbjoDDFtQ9HC/N/tZAzc/4lQAzbIMaHLNAXTt YO0iDaPMR7GpA5FSfXptymfnx1clOQJn78lCyxzEW778vHm7HxcFlRD9r4fU4fvx w1X0ZCY+GUrGIIGCjJ57YyBdHEVAmoQ7m82gzZ5Cr8UDM+guSuM= =FNMI -----END PGP SIGNATURE----- --=-sNzlin+/JdRut51wZnW7--